I had a relatively long post put together about writing code and how important it is to be consistent with your teammates. I had a few paragraphs on maintaining style, architecture, and keeping the essence of the code you’re working with. Instead of going through that, I boiled it down to a few basics that I run into often.

Keep the style consistent

If you have a corporate style, follow that.  Otherwise, the Snoracle code conventions are mostly your friend. I always have to grit my teeth when someone abuses this.  If the project is written in a K&R style, don’t complain when your Allman style classes get reformatted.  Checkstyle does a really good job at automating this at check in time, while the major IDEs have very good formatting tools.

Maintain the architecture

If the project you’ve been asked to maintain is straight JSF, don’t slam in your favorite DI framework because that’s all you know. Take the time to look through the code and get to know it.  Maintain the architecture whenever possible.  When it’s your turn to decide the design, you can do it however you want. Until then, it’s helpful to stick with the groundwork that’s already present.  Keeping the architecture clean is a huge advantage when it comes time for refactoring or retrofitting for missed requirements.

Follow the spirit

If a class has only 5-line methods, don’t slam in a 50-line monstrosity.  When all the parameters are declared final, take note, and do the same where appropriate.  If the class is immutable, don’t add javabean setters.  In other words, don’t redecorate your friend’s house when you stop by for a visit.  For good or bad, a lot of developers feel strongly about code they initially created.  If someone else isn’t considerate of the spirit in which that code was written, feelings can fray and productivity can plummet.

Don’t break things

Before you check your code in, make sure it compiles and passes all of the unit tests.  Continuous integration helps this situation, but you can save yourself embarrassment and the wrath of your coworkers by making sure things are ok before committing.  If you don’t have unit tests for your stuff, now is the time to write some.  No one likes a broken build, but it’s even worse when broken code ends up on your machine straight from source control. Developers have a hard enough time tracking down their own bugs.  Adding to that burden and making them fix yours is not appreciated.