

Ask HN:working with a company with anal coding standards - berito

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.<p>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
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...](http://www.amazon.com/Code-Complete-Practical-Handbook-
Construction/dp/0735619670/ref=sr_1_1)

[2] [http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsman...](http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsmanship/dp/0132350882)

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

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

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

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

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

------
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 :-)

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

------
jaachan
Would a pretty printer help?

