4 ms·

I thought the same thing. Try telling the go community that style consistency is overrated and that "go fmt" has some really bad styles in it. As far as I can t

I thought the same thing. Try telling the go community that style consistency is overrated and that "go fmt" has some really bad styles in it. As far as I can tell, in that direction, only dogma lies.

hodgesrm 10y ago
I believe this is less dogma than an engineering choice that some conventions are necessary to enable readability, avoid obvious errors (like forgetting braces around conditional logic), and make merges as easy as possible. Within bounds it does not matter what those conventions are so long as everyone uses them. Over time I have come to think this is the only reasonable way to approach coding conventions. Just to be clear, I personally dislike tabs and line-lengths over 80 characters. However, such choices have no bearing on the success or failure of any project I have ever experienced.
- __david__ 10y ago
  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

hodgesrm 10y ago

I believe this is less dogma than an engineering choice that some conventions are necessary to enable readability, avoid obvious errors (like forgetting braces around conditional logic), and make merges as easy as possible. Within bounds it does not matter what those conventions are so long as everyone uses them. Over time I have come to think this is the only reasonable way to approach coding conventions. Just to be clear, I personally dislike tabs and line-lengths over 80 characters. However, such choices have no bearing on the success or failure of any project I have ever experienced.

__david__ 10y ago
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