Paul Trippett
Do as I say, not do as I do
Home | C# Regions... When to use them? >>

5 Things to remember when coding in a team

Monday, August 25, 2008 6:51 PM

Whenever I tell one of my developers to do something a certain way I always get asked the question "why? doesnt it just take longer?". Well maybe it takes a little longer but Its not just because i am being a hard ass there is method behind my madness.

1. Format your code for readability:
Sure, you may understand your code inside out and know exactly what its doing but its may not always be you who has to edit the code. A few extra line breaks, proper tabbing, pretty code makes all the difference when someone else is burdened to read, understand and edit it.

2. Stick to the naming convention:
EUGHStrUPINSET, frmTest, cDataStructures, customerInformation whatever your convention, stick to it, its there so you all understand what a variable does. But IMHO dont let your naming convention be visible on public members stick to Camel Cased strings.

3. That super new functionality may be cool but...
Not everyone in your team may not understand it so whereas you maybe an ub3r l33t coder for using it. You just lost 2 days while everyone else now has to learn it. Thanks!

4. Comment it please:
It may seem straight forward but itsalways nice to know what you intended it to do just incase you wrote it with a hangover and its not doing anything slightly like what it should, if its purpose isnt commented who knows if its right or wrong.

5. Put order in your code and use #region #endregion blocks:
Why? For the meer reason I said so, I like it and it makes me happy

Feedback

# re: 5 Things to remember when coding in a team

I have to admit, I'm not a fan of regions.
I hate having to expand everything to read and understand whats going on. And I think that if you need to use regions, then you may need to consider that your class might be doing alot more than it should. However, that said, I suppose regions come in handle in form classes.

Regarding no.3, think Id have to disagree. If we all coded to the lowest common demoninator in the department, we'd never achieve anything new. This is especially true when you are surrounded by '501 developers', that dont really care, and are out the door by 5.01pm
Having someone in the team, inspiring and being creative can also have a positive effect.


8/26/2008 3:11 AM | Andyk

# re: 5 Things to remember when coding in a team

I'm with Andyk on this one. I detest regions. They slow me down and hide code. In fact that's one of the biggest reasons I hate them, they hide things. Methods that should have been removed or refactored. They hide how big your classes have grown (an indication that your class is doing more than it should) and they make it harder to find the code you're looking for.

And for number 4, if you're writing code for readability? Doesn't adding comments just increase maintenance overhead? We have a rule that says comment when it isn't clear and if you need a comment ask yourself if you can re-write that section of code so that is IS clear.

And for number 3, there has to be a balance. I find that as long as the developer isn't spending time writing the most efficient code possible (and thus increasing it's obfuscation and readability), I do want them to write the best code they can. Not holding themselves back at all.

8/26/2008 8:36 AM | George Clingerman

# re: 5 Things to remember when coding in a team

Thanks for your comments.

I generally put the obvious stuff in regions like Interface Implementations, things that obviously should be together. if you have a class that implements a couple of interfaces it can help finding the right function or entry point. But yes implementing it for everything would be time consuming and a little pointless.

A good namespace and class design should eliminate general code comments. The following is IMO a waste of time but I have seen it done: -

// Get the Customer from the db
Customer.getById(inCustomerId);

A lot of my customers like the API documentation to be generated direct from source code and putting the <summary></summary> blocks in the code is a one time investment in time.

However sometimes customer budget and time constraints sometimes dictates how something will be written so if you have a big function general comments are nice to show the flow or logic thats trying to being achieved.

I am all for my developers learning new technologies, but with all things there is a time to use them and a time not to. If the developer that originally wrote a piece of code, control etc is away, left, fired I have to explain to a customer why it took 2 extra days to fix a bug and either take a loss because of the learning curve or justify billing the customer for the time taken.

8/26/2008 10:03 AM | Paul Trippett

# re: 5 Things to remember when coding in a team

Yes I agree with you Paul, however I think given the choice of throwing aload of code into a form because noone understands the MVP pattern, or actually implementing the MVP pattern, Id definitely choose the latter because of its proven maintability and readability.

Taking time to do some regular R&D however is also invaluable and important for everyones education. Id much rather have someone on my team whose enthused and keen to try new techniques when they have time, rather than someone who will quite happily to what he's done for the past 3 or 4 years because he's not interested.

8/26/2008 11:33 AM | Andyk

# re: 5 Things to remember when coding in a team

For the ones that dislike regions, it does not take more than two keystrokes to expand or contract the regions, compared to the tremendous gain of organization that you get when you use regions.

Its precisely forcing new or junior developers to use regions that helps you sort through their mess and fix it.

Comments are mandatory. You don't want to be stuck doing maintenance on uncommented code that some developer did while he was smoking pot. Plus, it wont take that much of your time to comment your code and it definitely will save you a lot of questions from new developers that join the project and dont understand the purpose or reason of a given block of code. 8/26/2008 10:08 PM | Gabriel Rodriguez

# re: 5 Things to remember when coding in a team

people who use #region, #endregion deserve to be shot, sorry but it's true. 8/27/2008 4:52 PM | ssahloe

# re: 5 Things to remember when coding in a team

Perhaps more important than all of these. Remind yourself that the code is not yours. The code belongs to the team. There should be no "Why did you change my code?"

Also, as a team you should be doing code reviews. This is one way of identifying code that is not clear and needs comments to reflect the intent.

However, from a TDD approach (perhaps even BDD), your tests should do a pretty good job of documenting your intent. 8/28/2008 9:41 AM | Will

# re: 5 Things to remember when coding in a team

After many years of insisting that "The best comments are clear code", I've switched over to the other side. The code can only tell you what it does --- but not what is it supposed to do. How can you possibly refactor or optimize code with no comments? It would be impossible to tell what it the intended effect from an unnecessary side effect from a plain old bug. 8/30/2008 8:46 AM | James Curran
Post a comment





 

News

Twitter












Archives

Links

Syndication:

 
© 2007 Website.com. Valid CSS & XHTML Website template by Arcsin adapted by timheuer