Ask HN:working with a company with anal coding standards

7 points by berito 13 years ago | 14 comments

I am a humbly good programmer who always gets a good job done (speed/meeting specs) I do not care for other people's arbitrary coding conventions. Not do I care about wasting time writing tests. I hate camelCasing. Is it getDb() or getDB()? I don't care. Keep it as getdb() and don't waste my fucking time.

Now apparently my company will adopt strict code conventions and will make committing impossible if it doesn't meet the scheme. How have you got around this?

facorreia 13 years ago |

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.

Books such as "Code Complete"[1] and "Clean Code"[2] should help you with that transition.

[1] http://www.amazon.com/Code-Complete-Practical-Handbook-Const...

[2] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

EliRivers 13 years ago |

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.

bdfh42 13 years ago |

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?

If you are a "humbly good" programmer then you should be able to work with code conventions.

dotmanish 13 years ago |

A rockstar in a rock band must play tunes others can follow.

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."

Your call.

debacle 13 years ago |

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.

Camelcase is something that you pretty much come to accept as soon as you start writing OO Perl.

brudgers 13 years ago |

"I hate camelCasing"

Unless camelCasing shot your pa, this seems like a waste of perfectly servicable animosity.

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.

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.

berito 13 years ago | |

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 of absolute truth for a company

brudgers 13 years ago | | |

under_scores, camelCase

The fight will be vicious because the stakes are so small.

shortlived 13 years ago |

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.

berito 13 years ago |

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.

bdfh42 13 years ago | |

I would have thought that the feedback (so far) on your post would have shown you that the HN mood is that code conventions are not about "pretty" but are a fundamental standard for professional programming.

As an aside: code expected to be replaced "in two months" has a horrible habit of still being around in 10 years.

berito 13 years ago | | |

Sure, if it lasts 10 years, it's good code :-)

tluyben2 13 years ago |

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.

jaachan 13 years ago |

Would a pretty printer help?