Ask HN:working with a company with anal coding standards

I got around this mindset along the years, by learning about the importance of lowering the maintenance costs, improving collaboration and not depending on any single person to understand any given module or system.<p>Books such as "Code Complete"[1] and "Clean Code"[2] should help you with that transition.<p>[1] <a href="http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1" rel="nofollow">http://www.amazon.com/Code-Complete-Practical-Handbook-Const...</a><p>[2] <a href="http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882" rel="nofollow">http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...</a>

You could do everyone a favour by quitting. That way, you wouldn't have to adhere to standards, and they wouldn't have to put up with a prima donna.

Assuming that you work in a case sensitive programming language then conventions such as the one you identify are important for the net productivity of the whole team. Put yourself in the position of the team manager - what is best for the group?<p>If you are a "humbly good" programmer then you should be able to work with code conventions.

A rockstar in a rock band must play tunes others can follow.<p>I have seen numerous counts of "He is fast and efficient, but we end up suffering due to the (non) maintainability of his code", followed by "We had to let him go." or "He has been moved to this sole person project."<p>Your call.

What you're complaining about don't sound like anal coding standards. Anal coding standards is not being able to use HEREDOCs, not being allowed to write anonymous functions, being forced to use some stupid library that replaces the normal implementation of a language feature with a crappy, slower version.<p>Camelcase is something that you pretty much come to accept as soon as you start writing OO Perl.

<i>"I hate camelCasing"</i><p>Unless camelCasing shot your pa, this seems like a waste of perfectly servicable animosity.<p>Don't get me wrong, there are plenty of times where the standard is little more than a person with petty power turning their personal preferences into an enforced standard. There are also times when standards are applied to workflows that don't need standards because the product will never be touched again.<p>Plenty of organizations have standards because it looks good on a list of QA practices. Only a subset of those organizations enforce them with a sustained effort.

I'm a programmer because I like solving problems and designing solutions. I could care less about language, coding standards, etc. You are focusing on the wrong thing, or, you really shouldn't be a programmer.

Edit: (addition) I mean I hate camelCase as an enforced standard. I use it when it feels useful. I use underscores as well when I think they are fit. I just don't like being one standard pretending to be absolute truth for a company. If the company is a startup, it's even more important that we get to release as fast as possible, instead of fretting over if the code looks like poetry or not. The odds are, the bit of code will be obsolete as a feature in two months.

You are not posting this on Digitalpoint forums; you cannot expect people to 'help you' with this here on HN, right? Because it is important and most people here know it is.

Would a pretty printer help?