FSFE-defined coding standards?

Should FSFE provide some kind of platform for community to discuss and propose coding standards?

Rationale

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.

Practical Example

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.

Bad code:

#!/bin/bash

number="5"

if [[ "$number" =~ [0-9] ]]; then whatever; fi
  • Works only on systems with dynamic linking
  • Bash is not part of standard portable OS → Not portable

Good code:

#!/bin/sh
# shellcheck shell=sh # Written to comply with IEEE Std 1003.1-2017 <http://get.posixcertified.ieee.org/>

number="5"

case "$number" in [0-9]) whatever; esac

Maybe we should recommend one of the standards? For example we could join the existing work, ie check this: styleguide | Style guides for Google-originated open-source projects

I am not familiar with styleguide | Style guides for Google-originated open-source projects, but from quick look it seems to be very bias and influenced by how google writes it’s code without a sufficient peer-review…

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.

Compulsory: https://xkcd.com/927 :wink:

I am not a big fan of “coding standards” in such a general and abstract
form: in my experience, too strong a focus on them tend to obscure
the important part, which is /communication/.

As free software advocates, our aim is to write software which can be
used, read and understood by other people. Coding standards can be a
tool towards achieving that. No more, no less.

Wouldn’t the GNU coding standards [1] be a “natural” starting point
for us, anyway?

Cheers

[1] GNU Coding Standards

– t

I don’t think that more standards is a bad thing as projects can just choose which standard they want to follow with option to change anytime for the code to be adapted by it.

And i think that eventually if there are multiple standards each enforcing the same thing that they would merge together.

Would agree that standards has to be flexible and make sense for the project to benefit from them

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

Hi Jacob,

Jacob Hrbek via FSFE Community no-reply-discourse@fsfe.org writes:

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. :slight_smile:

Happy hacking!
Florian

1 Like

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 like the idea of both

In general

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

Programming languages

I would argue for standardization of:

  • Indentation: By allowing everyone to use whatever indentation they are comfortable with assuming formatter in place such as GNU indent or the once packaged with programming languages while discouraging upstream to enforce unwanted standards such as src/ch01-02: Remove note about spaces vs tabs by Kreyren · Pull Request #2468 · rust-lang/book · GitHub
  • 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.

Python shilling

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).

The show “Little bits of lisp” (https://www.youtube.com/playlist?list=PL2VAYZE_4wRJi_vgpjsH75kMhN4KsuzR_) should make it painless to understand the language.

Note that lisp is portable beyond POSIX as it appeared in 1958 before C programming language which POSIX relies on.

Hi Jacob,

Jacob Hrbek via FSFE Community no-reply-discourse@fsfe.org writes:

i would like to see a best practice development process enforced that
consist of:
[…]

How is this different from advice for non-free software?

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

What’s the difference between a programming language and a scripting
language?

Happy hacking!
Florian

I don’t understand the question.

subjective, my definition would be:

  • The code is being intepreted without compilation → Scripting language
  • The code is being sent to the compiler where it is translated/compiled in machine code → Programming language

Note that i consider lisp being a hybrid of those two where i prefer to use it as a replacement for scripting language.

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.