4 ms·

My point is that it's dogmatic for the entire community to use a single style. I've worked on countless different C programs over the years, most with their own

My point is that it's dogmatic for the entire community to use a single style. I've worked on countless different C programs over the years, most with their own unique style, and while I think it's good for a project to use a consistent style, using it across every project seems dumb. Cross-project style consistency doesn't buy us anything reasonable--there's no "engineering" about it. Also, braces around conditional logic isn't what I'm talking about here (since that's not a "go fmt" style choice--that's the language syntax).

hodgesrm 10y ago
This is likely to be controversial but code conventions are like GOTO statements for me--it seems best to adopt baked-in formatting conventions so that it's no longer possible to waste time and energy arguing about them. Also, it avoids the exertion of chasing people who don't do it consistently and mess up merges or ability to see diffs. Finally, it eliminates the bad feelings that result from religious arguments about code formatting. Most project teams have limited resources to come up with a solution that is close enough to correct to make the project pay off. In new technology there also tends to be a small set of technical issues that are hard and that you must get right--nothing else matters that much if you fail on the core. I am pretty heartless about anticipating things like code conventions, security requirements, legal review, etc. and just following the rules or otherwise making them non-issues for the project team in areas where it does not fundamentally alter the outcome. Edit: clarification