Should FSFE provide some kind of platform for community to discuss and propose coding standards?
The (F)LOSS ecosystem is currently mostly focusing on quantity over quality which results in bloat of software that is not reliable in a mission critical environment (and thus making it inferior to proprietary software) or software that requires “reinventing the wheel” because of authors bad decision (lack of abstracting → Malpractice).
This proposal is expected to contribute to the solution.
Example enforcing IEEE Std 1003.1-2017 to check if variable ‘number’ storing integer 5 is passing reqular expression [0-9] in shell vs bourne again shell.
if [[ "$number" =~ [0-9] ]]; then whatever; fi
Works only on systems with dynamic linking
Bash is not part of standard portable OS → Not portable
# shellcheck shell=sh # Written to comply with IEEE Std 1003.1-2017 <http://get.posixcertified.ieee.org/>
case "$number" in [0-9]) whatever; esac
Which seems to be a common on the currently provided standards with few exceptions such as IEEE so i was hoping that this way we could make it community maintained enforced by a trusted and competent authority such as FSFE.
From my experience with it and quick looking through it now i think that it’s not flexible enough e.g. it’s enforcing formatting for C which i don’t see a reason to enforce as long as there are tools like GNU Indent that can be implemented as Continuous Integration to format the code. → Allowing the developers to use their preferred formatting that they are comfortable with
Should FSFE provide some kind of platform for community to discuss and
propose coding standards?
I like your rationale, but I’m not quite sure where we come in. There
are software tools out there to enforce certain standards that can be
applied depending on the individual project’s needs. The FSFE mainly
educates people about Free Software and we do get involved in
development issues when it matches this purpose, for example with REUSE.
However, I’m not quite so sure that providing coding standards is
something we should do. And even if it’s part of the FSFE’s mission,
then I still see the issues that others have pointed out about how
abstract those guidelines would have to be to fit all sorts of projects.
But that’s just my opinion right now. It may change with additional
input and others may feel differently, of course.
I was rather thinking of basically a database of good practice that project developers can cherrypick from and discuss new standards instead of one huge standard that is supposed to apply to everything.
I don’t understand what exactly you are looking for? Coding standards by FSFE for EVERY programming language or some kind of “meta-standard” for all?
Both ways look quite problematic to me: For example in my prefered language Python there is already a standard (PEP8) well accepted by the community.
So a “meta-standard” would likely interfere with it. Or develop another specific one without a need?
Regarding your example with shell script: If you are looking for something readable & portable, maybe this is just the wrong tool? Why not use Ansible (or Puppet, Chef etc.) instead for configuration tasks or something more readable & portable like Python?
i would like to see a best practice development process enforced that consist of:
Abstracting: Figuring out what you want, why and how to achieve it and why to achieve it that way
Brainstorm: To avoid design-induced issues such as bad implementation by discussing the abstract with qualified inviduals to avoid bad practice e.g. GTK that give raise to movements such as https://stopthemingmy.app/ due to the bad design.
Peer-review: To make sure that the code that you’ve created is not “unreliable garbage”.
Documentation: To allow for an easier contribution as public would have easier time understanding the code
Automatization: To run the code through tools that enforce code quality
Translations: Implementing translations handling to make the software available for people who are not confident in english.
Avoiding duplicate code: Lots of developers are doing a mistake of maintaining a multiple pieces of code that does the same thing or are just a copy of one another, this should be avoided at all cost since it creates a maintenance overhead.
Providing a standard development environment such as packaging the source code with workspace.code-workspace or init.el to make it easier for new contributors to contribute
Optimizing the built binary to be respectful of mental disorders such as removing the mentioning of birth to make the software more comfortable for people with Tokophobia (Tokophobia - Wikipedia)
I said i don’t think that more standards are a bad thing as it allows the developers to cherrypick and discuss which standards they want to enforce to basically enforce how the project is expected to be developed which (at least in my experience) is good practice in proprietary development as it saves money by avoiding unwanted designs and allows rewrite of the source just by changing the standard in a controlled way.
So developers should be able to use PEP8 with other standards if they so desire as all projects are different and it doesn’t make sense to enforce one standard to be used for everything.
I use shell for examples as i assume that everyone who uses Free Software is able to interpret what am i trying to express through it since it is what is used in the standard terminal.
I disagree that python is more portable then POSIX sh as it’s not part of POSIX and so it doesn’t conform the IEEE Std 1003.1-2017 standard and is generally less efficient in terms of the use of processing resources in relation to the time.
I would also argue that the used syntax is simple to learn (as all programming languages should be) at the cost of maintainability due to the frequent changes to the language and syntax with dependency on indentation and requirement for duplicate code thus waste of time that should be avoided.
Consider using lisp https://lisp-lang.org/ instead which i see as superior alternative to scripting languages and even to the programming languages in terms of langauge flexibility since it allows redefining of primitive functions to adapt the programming language directly for the project that it’s needed for e.g. Emacs Lisp while making you a better developer in the process (it’s design makes you to realize that you can think outside of the box on other programming languages).
Agree that forcing the standards on people is a bad idea.
My implementation would be to not enforce anything unless the developer decides to use the standard after which the code should be reviewed for the standard compilance
As discussed above the concern is trust and robustness of the project so that it can be used as superior alternative by governments and businesses that require the software to be designed for mission critical environment.
I don’t want to enforce coding style as long as there is CI implemented that formats the code e.g. GNU Indent.
I guess this could be phrased as “coding recommendations” to make it a subject to the current standard maintainers instead.