where i worked at Qualcomm, there were stlye guidelines that required braces, on separate lines wherever they could potentially be used. A single line if statement had braces. The style guide also dictated indentation (4 spaces) and limited line lengths, with exceptions, to 80 chars, as well as placing function return type and arguments on separate line so that there an be comments for each
the purpose was to make code written by anyone very similar making it easier to read and avoiding personal perferences. I had to write a Linux driver that was submitted to Android. Android had similar, stricter guidelines (some of my typedefs had to be undone).
there's a story about Ken Thompson and Dennis Ritchie both writting the same function. Both versions were identical to one another.
(no, specifying 1000000UL was not dictated in the guidelines)
If you work for someone or something, it makes sense to dictate style guidelines that everybody has to follow. I dictate style guidelines to myself, but of course i rarely give myself a hard time about it.
If everybody uses the same rules, it makes the overview easier for everybody.
do you think you would be better of if you weren't consistent? Being more consistent is even more important when you don't have someone reviewing your code
a consistent style results in patterns that are easily recognized when broken.
I think if I ever did work for someone with a style guide, I'd probably have to make a my style to corporate style conversion tool.
If, for example, the style guide dictated the use of Buddha Notation, which hurts my brain, that would have to be enforced by my outgoing translator. After having been fixed by my incoming translator.
And style dogma can be taken too far. Roll into some places, or some languages, with a firmly embedded style that isn't familiar, and code just looks weird.
When in Rome kinda thing. Like when it was so easy to spot C programmers that learned how to program first using FORTRAN.
Arduino sketches (!) mostly follow a standard pattern. Exceptions to that can make reading them harder, even if it satisfies some style guide somewhere.
Note: there is zero chance of me ever working as programmer. And if I did, I would probably quit when the style guide hit my desk, or at least after coming across the third or fourth thing in there that I violently disagreed with.
Coding for the UNO doesn't have to be like working for the man. Programs can be just as readable, and at least autoformat helps. Consistent style is nice, so is being able to read any of the popular style variations.
i think you'd find that most decent style guides aren't unreasonable and are probably very similar because they're based on the one for Linux. So adopting it would make it easier to read most other well written code.
where i worked at Bell Labs there wasn't any style guide. I did however hear that code for the ESS , probably the first commerical code using Unix, C and all those tools (e.g. make, sccs, cscope, ...), and hardly trivial, had a limit of 2 screens, 80 lines for function. If bigger, just break it into smaller functions.
but no style guide is going to prevent someone from writing code poorly, such as coy&paste.
No, but preferences grow over time and sometimes change a little.
That yes. Though also something not dis-pleasing to the eye can important.
Naming conventions relating capitals, where to put braces etc. I know that if a call a function starting with a capital, it will be a function in 'my' code, normally and not one part of an external library of some kind, but there are exceptions.
I rarely put comments on a line by themselves etc etc.
but there is nothing one can do about what chess players call 'a blindness of the eye'
Yesterday i spend near an hour looking at a bit of code
uint32_t uniFlag = 0;
while (universes) {
uniFlag << 1;
uniFlag |= 1;
universes--;
}
uniFlag = uniFlag << (UNIVERSES_PER_OUTPUT * out); // so no extra shift when out == 0
artnetUniFlag |= uniFlag;
But only after creating a small sketch with debug information in it, did i see
C:\stuff\SW\Arduino\_Others\Tst\Tst.ino: In function 'void setup()':
C:\stuff\SW\Arduino\_Others\Tst\Tst.ino:11:13: warning: statement has no effect [-Wunused-value]
var << 1;
// -----------------------------------------------------------------------------
void setup ()
{
Serial.begin (9600);
int var = 1;
for (int n = 0; n < 8; n++) {
Serial.println (var);
var << 1;
}
}
void loop ()
{
}
there were programs like lint for catching stylistic errors and suspicious constructs. I think of those features are incorporated into todays compilers.
( time for a new language and a new compiler to add all those tidbit features to)
Just implement a hook to the (pre) check in procedure to format the code to “standard style”. This will optimize the comparison of the changes as previous and current version are in the same style independent from the “preferred style of individuals”.
What you see is that people will adapt in their own pace to the “standard style”, and if not the system can cope with it.
