27

What I mean by that is, how do you go about developing on a code base you share with developers who have been working on it for years and are very familiar with it?

I don't want to step on anyones toes, but I get not so subtle complaints about the way I do things, whether it be how I whitespace my code, or how frequently I checkin to SVN (too often). So while I can change those things easily -- I want to be a better team developer in general.

I'm not sure what to do, other than ask, but maybe you guys have some thoughts I could put to practice.

UPDATE

There isn't any style guide to speak of -- it's just people aren't used to sharing the codebase. Everyone has their own little siloed code-world.

This is a perl shop, but I'm sure these apply to any language

UPDATE 2

The CTO who later became CEO was a complete megalomaniac and was the primary source of these complaints. If you didn't do things exactly how he liked, whether it was using a Mac, or Emacs, or 4 tab spaces instead of 2, or dress a certain way, you were inferior. It was a horrific situation that I tried to correct, but the only correct answer for me was leaving.

I am convinced that this was an instance of bullying in a workplace, and subsequently, I'm more aware of what might be subtle bullying and inappropriate behavior in a work environment.

To any developer looking for answers to a situation like this, leave immediately. You can't teamwork your way out of a bad team situation.

16
  • 3
    Do they feel you check code in too often? Or too seldom? Dec 13, 2011 at 19:40
  • 3
    At the very least, double checking your pointers will stop you from offending the computer (xkcd.com/371)
    – riwalk
    Dec 13, 2011 at 19:52
  • 4
    If you code in C#, propose that everyone uses StyleCop. If you code in another language, looks for similar tools. Let the blind piece of software be the arbiter in 80% of the cases.
    – Job
    Dec 13, 2011 at 19:53
  • 3
    You shouldn't be checking stuff in unless it's "done", to a reasonable extent. So you should have updated your working copy to the latest code (resolving any conflicts), built successfully locally, and ran tests (or, if you don't have automated tests, done your own smoke tests to verify that your changes work as expected and don't break something else) before checking in. But if you're doing that, and they still feel you check in code "too often", I really don't see their point. Dec 13, 2011 at 20:45
  • 2
    If you're concerned about losing work or creating "checkpoints" for work that might break stuff, you should be doing that work in a branch, not trunk. You can still do that, even if they keep working out of trunk. Dec 13, 2011 at 20:48

7 Answers 7

38

Ask. That is, ask the folks you work with. Do your best to stick to the established style of the existing code. Ask especially if there's a document list of coding standards, and follow it. If there isn't one, write up a first draft based on what you observe in the code and then ask the other team members to critique it. You'll do the company (and new developers who come after you) a service by starting to document the accepted coding practices. The only risk is possibly getting caught in the middle if it turns out that the old-timers don't agree with each other on what is or isn't acceptable.

Also, don't be afraid to be yourself. You might be the new guy, but you're a member of the team, and your opinions are valid. If you can think of better ways to do something, suggest it. Respect the other team members and the established way of doing things, but don't let them push you around. The company wouldn't have hired you if it didn't value your input.

It'll help a lot if you can find someone on the team that seems friendly and particularly willing to answer questions. (If it's a good team, that should be everyone, but teams aren't always like that.) Your boss may have assigned someone to help get you started. Use that person as a resource. Write down questions as they occur to you, and then ask that helpful person to answer them from time to time.

As for checking in code "too often," why not create your own branch for your periodic commits, and then merge back to trunk when your code is ready? There's no harm to anyone else in doing that, and when your coworkers see you getting benefits from SVN that they'd like, they might follow your lead.

2
  • 14
    An alternate to branching is to use GIT locally. It has a seamless SVN interface, and they will never see your hourly commits.
    – mattnz
    Dec 14, 2011 at 9:50
  • 4
    +1 for being proactive about creating a coding standard document from the code you see and getting consensus. It's utter BS to be criticized for failing to follow one person's coding style that doesn't itself follow anyone else's. Jan 24, 2012 at 3:01
24

Regarding whitespace: Just do it however the code already does it. Go with the flow.

Regarding SVN checkins: Document them very clearly. That helps people understand what's going on in the code. (Followup: What are their objections to the frequent checkins?)

In general: Start building up a coding standard document. Don't try to fill it with 100 rules. Just add rules as they come up.

Also: Ask questions of your fellow developers. That gives them an opportunity to weigh in before you do something they won't like. Plus, it builds relationships. Plus, you learn more about how the shop works.

1
  • 1
    Decent answer, but I don't like the "Go with the flow" on whitespace necessarily. If it's reasonable (but just not how you would do it), yes, go with the flow. But, as in the case with code that I have seen and there IS no consistent whitespace, then establishing good practices (as suggested by Caleb) can go a long way.
    – JasCav
    Jan 23, 2012 at 16:28
7

As far as code formatting style (whitespace, tabs, where braces go, etc.) you should follow the prevailing standard in the code. If there isn't one, I don't think they have much to complain about. When it comes down to it, whether you put braces on their own line or not, put spaces around method parameter lists, etc. is personal preference, and you should yield to the prevailing style because in the long run, it really doesn't matter. What matters is being consistent.

When it comes to checking code into SVN, I would try evangelize what I feel is the right way to do things, rather than letting myself be steamrolled. I don't check my code in unless it builds and passes tests, and if I'm making several unrelated changes, I break my work up into several commits. If something will be broken for a while, I create a branch and do my work there. Commits get descriptive comments. This works better in my experience than the "check in a pile of changes on Friday at 5:00" method, and it seems to be the prevailing "best practice" according to most of what I've read here and elsewhere.

4

First read their coding conventions document (if they don't have one then ask them to write one so you can follow it)

Then take notice and make a conscious effort to follow that and what they say. It may seem to you that they are being harsh but coding standards are important, its better to point out now whats wrong rather than let it develop into a problem later when you are making larger changes.

I'm sure you will be doing the same in a year or twos time when some newbie is stepping on your toes :)

3
  • yeah they dont have any conventions, they just havent had any new developers in a long time.
    – qodeninja
    Dec 13, 2011 at 20:22
  • 1
    @codeninja then how can they complain if you don't follow them? They have to agree on a set of conventions before they can expect you to change how your coding. Tell them that Dec 13, 2011 at 20:44
  • this place was a nightmare, the CTO who later became CEO was a complete megalomanic. If you didnt do things exactly how he liked, whether it was using a Mac, or Emacs, or 4 tab spaces instead of 2, or dress a certain way, you were inferior. Total nightmare.
    – qodeninja
    Feb 19, 2013 at 18:38
3

Ask for the company code standards. Pay more attention to detail. If you see others follow a very specific form of white space and brace patterns, then follow them. As a Sr. you could argue this to be nit-picky, but as a Jr. or new guy on a project you need to show that you can follow before you can lead.

Also, understand that any new developers on a project will indeed have a necessary "ramp up" time. So don't worry yourself over that.

1

The best thing you can do is to follow the advice they give you. There's no way to tell ahead of time what they want. Unless you're psychic.

However, i would suggest that as people give you advice, you document it. Do you have a wiki? If so, use it. If not, a text file checked in with the source code might be a good idea. Build up a well-organised programming guide. It will help you remember how to do things, and if someone contradicts earlier advice you've been given, it gives you a reference point to discuss the inconsistency. Plus, when the next person joins the team, they won't have to go through what you're going through.

I would suggest you don't attribute the advice in the document to individuals (so "code blocks should be indented by three spaces", not "Bill told me that code blocks should be indented by three spaces"). However, if you can record that information in an unobtrusive way (eg in the commit comment, write "added rule about indentation based on Bill's advice"), then it might be helpful in resolving contradictions, because you can immediately get two points of view on something. What i'm thinking about here, really, is that if you're given contradictory advice, you need to avoid becoming a football being kicked around by two colleagues who disagree on something. It's a bit of a cover-your-arse approach, but it might be prudent.

0

An easy one is to find the style guide and follow it. Most don't have anything too offensive in them, and will prevent you from offending others.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.