Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What happens when the style guide authors inevitably declare that no lint messages should be disabled, ever ?


Well, that's a self-inflicted damage, isn't it? You can move to another team with less brain damaged style guide authors.


Style guides are usually per company or at least per department. Leaving them behind isn't usually in the cards without severe other consequences.

I usually write a python program that doesn't complain about style violations, it just fixes them, like autopep8, but with much more stuff, like correctly capitalizing function names, variables, making strings consistent, making or taking away long-quotes, putting conditions in ifs, even renames shadowed variables (built it in last week after what feels like the 100th time I hit a bug due to shadowing) ... Makes people wonder how I can possibly program so fast under such onerous rules. On the downside: I work here now for 6+ years, and still don't know (or care) about most of the style guide, and frequently get confused when people ask questions "because you have written the most code, you must know, right ? Capitalize functions or not ? ... Ehm, well ...". Also, people ignore these things, so I must run it on any file I edit and submit a "style fixes" cl before doing anything else. But since git became an option, not much of a problem.

That's the trouble with style guides: 95% of what they do COULD have been implemented in editors if we demanded that style guide authors weren't "architects" and policy-makers, but programmers that really know what they're doing. Very little they do requires a policy, it can just be described as a parse-tree-transform. Instead, they're just people who feel they can just push their opinion on a large group of people, just because it makes them feel a bit better. That they can't actually program a fix, but instead just create another problem, doesn't seem to bother any of them, ever.

And we actually reward people for this. I don't get that. These people CREATE a problem, then somehow negotiate this style with a department, slowing everyone down for no good reason other than that they don't know how to do it automatically, and they usually actually get rewarded for providing a bad solution. Like they "introduce standards". Even just providing a style-guide-checker with a consistent interface (so IDE integration would be easy) is too much to ask at every place I've ever worked.

No, they substitute 10% of the all labor in this company for the job a simple perl script COULD do.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: