Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Inheriting applications at a new job

When inheriting applications at a new job do you tend to stick to the original developers coding practices or do you start applying your own?

I work in a small shop with no guidelines and always wondered what the rule was here. Some applications are written very well but do not follow the standards I use (variable names etc...) and I do not want to "dirty" them up. I find my self taking a little extra time being consistent.

Others are written very poorly and it looks like the developer was changing his mind every keystroke...

ADDITIONAL THOUGHT

What about when I start my own projects? So now I have introduced a new coding standard to the mix:

  1. The good code - but not my style
  2. The bad code with bad practices and lack of standards
  3. My own standards
like image 876
Miyagi Coder Avatar asked Jan 28 '09 15:01

Miyagi Coder


2 Answers

If there are standards evident in the code, you should stick to them. If there aren't, start introducing your own.

like image 65
gkrogers Avatar answered Oct 05 '22 23:10

gkrogers


If there are multiple developers who work on the same module, don't change the style.

If you will hand it off to another developer in the near future (this role is temporary), don't change the style.

If you are taking complete, exclusive, permanent ownership of the module, change it, but follow these rules:

One change at a time.

Fix all indentation to your liking at once, and commit that change.

Fix all brace placement to your liking at once, and commit that change.

Fix all other formatting to your liking at once, and commit that change.

Fix all naming to your liking at once, and commit that change.

Don't spend a lot of time on it.

If it takes more than an hour or two, then cut back.

Make the commit description clear.

So you can quickly ignore these changes when analyzing change history.

Use automated tools

to make sure the result is consistent and complete, so you don't have to mess with it again.

Run your tests

Just because your changes shouldn't affect behavior doesn't mean they won't. (Triple negative, ouch!)

Make sure everyone knows what you're doing

Someone might have a change hanging around that they want to commit now, and it'll be painful to merge with your changes. Also, you don't want anyone to get surprised and go tell your boss before you do.

Don't do it again

This is a one-time thing.

like image 44
Jay Bazuzi Avatar answered Oct 05 '22 22:10

Jay Bazuzi