("bad" by whose definition? how do you measure that empirically?) make for a weak argument. The points you want to make are best supported with evidence, not anecdote.
Let's start there and try to actually discuss the current good
standards or practices that we either actively follow or should
adopt.
Provided you even agree that any change of the existing "way of
doing things" could be remotely beneficial, please kindly share
your
thoughts and ideas of "good" coding practices then.
I'd personally determine the definitive lowest end of the quality
scale is code simply runs and functionally does what it should do.
Everything else is a gradient of "quality", be it human or
technical quality.
To give one or three examples which all already came up in this
thread ...
1) Having the convention to break lines after 80 characters is a
for-humans quality of the code. The interpreter simply does not
care.
But supposedly there are (were) reasons for this rule / convention
to be in place?
Since there were voices calling for this to be changed, are there
metrics to determine how useful this still is?
2) I'd argue that PEP8 ([1]), e.g. via Flake8
or Ruff, which used for many projects'
code is yet another (externalized) convention of coding practices.
But there are different levels of adoption and exceptions lowering
the advantages of unified coding styles.
OpenStackSDK did switch to automatically formatting the code with
black. While an initial big commit, there are no more variations
introduced by different people contributing their code - the
machine takes care of that. So does it make sense to adopt this
for other projects
and align "OpenStack" a bit more?
3) On the argument of adding type hints I'd say it's like memory
safety which is arguably only advantageous if you make mistakes.
Having types just helps to avoid a whole class of bugs (computer
shouting at dev if I may quote Sven here) and also makes
the code much more approachable. Also it allow to become quicker
when refactoring things in a larger code base to now accidentally
introduce bugs.
Let me add two examples of such bugs that were found this way in
[3] and [4] (both I quickly found searching for "mypy" and "bug"
in Gerrit).
Not to sound melodramatic, but I believe there is some amount of cry out to make contributing to the OpenStack code base more fun to contribute to again.The status quo wins by default, always, and it is incumbent on those proposing change to make a compelling case for any needed investment on the part of others
Regards
Christian
[1] https://peps.python.org/pep-0008
[2]
https://github.com/openstack/openstacksdk/commit/c946294bddd0ad37b707c7f993cdbc4706c00d00
[3] https://review.opendev.org/c/openstack/cinder/+/909689
[4] https://review.opendev.org/c/openstack/openstacksdk/+/900710