HN Explorer

Ask HN:working with a company with anal coding standards

7 points by berito ↗ HN
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?

15 comments

[ 4.4 ms ] story [ 20.8 ms ] thread
bdfh42
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.

jaachan
Would a pretty printer help?
[deleted]
(comment deleted)
EliRivers
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.
dotmanish
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.

tluyben2
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.
shortlived
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.
debacle
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
"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
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
under_scores, camelCase

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

berito
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
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
Sure, if it lasts 10 years, it's good code :-)