@sir Could someone explain this rule? "Programmers SHOULD NOT include other headers."

Does it have to do with compile times? Feel like I have heard that before.

Also is the link for "features to avoid" broken for anyone else?

@tristan957 compile time is one, separation of concerns is another, simplicity of the preprocessed source is another

@sir no problemo. Was a good read, and I am finally convinced two tabs for continuation lines is the way to go.

@tristan957 @sir That one got me confused until I figured out that it forbids inclusion of headers in *other headers*. Not sure how or if to rephrase it.

> Programmers MUST use enums over #define or magic constants.

aren't there constants you can't express as an enum? afaik the underlying type is usually int.

@sir Very nice guide! But could you expand on the reasoning behind this rule?
> MUST align case branches with the switch statement.
I'm assuming it has got to do with the 80 cols limit. I normally indent the case statements too, as it's visually easier to jump pass the entire switch statement.

@p two indents for one section of control flow is not great, and it helps with the 80 col limit yet

@sir never really thought of it in terms of a single control flow section. And then it makes sense to me to be thinking of the case directives more as labels, which aren't further indented.
Thank you for the clarification.

Speaking of labels, the guide doesn't state indention rules for labels. I believe it's pretty standard to have them unindented. But I have seen cases where they were. Perhaps the guide should spell it out?

@p they should be unindented but you should also be using them rarely enough that it doesn't need to be called out in the style guide

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!