How much attention do pay to coding style?

Pages: 12
there are coding guidelines made by experts everywhere, even on MS site what is lacking is people adopting them
I think most people who are working alongside others already have their own team guidelines, by necessity. Otherwise code with multiple authors simply won't work. And newly forming teams definitely consider well-known public guidelines like C++CG along with whatever the devs themselves bring to the table.

Even the public guidelines are usually such team guidelines gone "open source". C++CG was internal to one of Morgan Stanley's C++ teams when Bjarne worked there. Dozens of other teams in the same company had guidelines too, some more, some less exacting - they just didn't find it useful to put them on github.
I see many repositories have some kind of guidelines and style rules, however very very few are comprehensive as the public ones.

What I dislike the most is a semi huge repository with not a single code comment.
You are supposed to "precompile" all the code in your head if you whish to make use of it or to contribute.
@helios
btw. I couldn't resist to thank you for your sample solution to the size of DWROD,
I've just updated my code and it feels cool to know no data overflow will happen :)
No problem. I've just been using that pattern so often the past few months I have it memorized.
its a slick fix ^^

our code style is simple with the unusual bullet that says "match the style in the current file you are editing". There are rules, but that one acknowledges the many authors over many years.
jonnin,

That's interesting rule, I can imagine where this could be useful...

ex. when you're using 3rd party code and you don't want to change code style because you're fetching changes from upstream and want to limit changes to functionality only for better tracking purposes.

for ex. if you change style to your own then having control over what was from upstream becomes more difficult (since your style would modify every update)
A few years ago a coworker added a Git hook that ran a linter over the codebase after committing. I got so sick of reverting changes every time I committed because that fucking script wanted to touch every line in every file. I ended up just globally disabling git hooks from running on my machine. And yeah, the reason I hated it was for the reason you bring up. It makes the commit history useless.
I can see running a linter on the codebase at a set period -- say once a month or week, even end of the day -- but every commit?!? That sounds like something I'd do, at first. And then realize after a couple of lint runs it was defeating the purpose of version control with Git, etc.

Was this lintering approved by the Pointy Haired Bosses and Management?

Luckily I don't have to worry about others messing with any of my Git repo code ATM. Any problems are directly and unequivocally My Fault! I do make a lot of 'boo-boos'.
I can see running a linter on the codebase at a set period -- say once a month or week, even end of the day
It depends on what it does. If it's some kind of static analysis tool that tells the programmer about possible issues, that can run often, it's no problem. If it's a tool that reformats the code in some way, it should only be run before new code is added to the codebase in bulk, to make sure it matches the style of the existing code and if it's unnecessary (or impossible) to preserve history. A reformatting tool should never be run on an existing codebase, unless the history doesn't matter.

Was this lintering approved by the Pointy Haired Bosses and Management?
We only check technical decisions with our teammates, not with managers. It just so happens that this guy decided to add the hook on his own.
the frequency and volatility are the key.

if you run one every 5 min on a 500k file code base, odds are it usually just does nothing after the first time, only fixes one file here and there depending on team size and activity. But its changes will mix in with human changes and be more frequent, harder to isolate and validate etc.

if you run it once a month, many more things may have changed, and you get a bigger edit, but its all in one place and infrequent.

running it infrequently with its own name and scripts and all, its just going to change your repo to have an entry that linter changed 53 files at 2am on Saturday, which the team can see it outside of everything else that normally happens, etc. I see no problem with that. Even if it screws something up, its isolated away from normal code changes, easy to undo or something. With todays tools, it can run, test itself, undo & email alerts on any failure, and be all ready to go monday morning with minimal fuss.
Last edited on
Registered users can post here. Sign in or register to post.
Pages: 12