The Artima Developer Community
Sponsored Link

Weblogs Forum
What's the Most Effective Code Style Policy?

43 replies on 3 pages. Most recent reply: Jul 25, 2007 5:37 PM by Erick Reid

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 43 replies on 3 pages [ « | 1 2 3 | » ]
Tim LS

Posts: 37
Nickname: parchandri
Registered: Jul, 2005

Re: What's the Most Effective Code Style Policy? Posted: Jul 14, 2007 8:58 PM
Reply to this message Reply
Advertisement
> It's not really a parameter object a la Martin Fowler's
> Refactoring book, because it as interesting behavior. If
> you call its render method it will spit out the web page
> (or whatever it is) using the data that was passed to its
> constructor. We put that data into an object first
> primarily so our controller tests can just check the data
> not the string of characters produced by render.

OK, sounds more like a method object. I see: doing it that way means you don't have to e.g. parse the rendering result.

>
> I wonder though, whether it would
> > be easier to get those parameters via queries, rather
> than
> > storing them as members.
> >
> What do you mean by "get those parameters via queries?"

I meant instead of getting them as parameters, holding ptrs to respective sources - it can get them from via accessors, (and then expose them via its own accessors or whatever).

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: What's the Most Effective Code Style Policy? Posted: Jul 14, 2007 11:15 PM
Reply to this message Reply
> > W. Edwards Deming opined that Bad Quality would drive
> out
> > Good Quality. Kind of a corollary to Gresham's Law.
> He
> > was not happy about his conclusion.
> >
> Where did he do that opining?

of course, now I can't find the cite. OTOH, if you read him, that's his point.

another view:

http://en.wikipedia.org/wiki/Gold_Exchange_Standard

Stiglitz is a very smart guy.

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

The 95% principle Posted: Jul 15, 2007 6:17 AM
Reply to this message Reply
Set up a coding style and demand at least 95% compliance. This rule eliminates most discussions about 'minutia'.

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 4:25 AM
Reply to this message Reply
My view: Normalize style, including where to place braces, how to place spaces, and anything else.

The goal should be for any programmer to feel equally at home in any part of the code base, which means that code written by one programmer should be impossible to distinguish from code written by another programmer.

Over time, this makes it much easier for somebody else to drop in and change another programmer's code, for instance because the original developer has quit, or because you have global collective ownership (which I like, though I prefer to do it "softly" - when somebody edit, they confer with the original author unless the change is totally obviously the right thing, or the original author is unavailable.)

I agree with the description earlier about how to get these guidelines: Start with a limited set, and expand the guidelines (after collective discussion) each time you notice a discrepancy in style.

disney

Posts: 35
Nickname: juggler
Registered: Jan, 2003

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 5:52 AM
Reply to this message Reply
IMO coding standards should be enforced BECAUSE THEY'RE SO UNIMPORTANT! Having a consistent coding style allows you to ignore the style and layout, and concentrate on what's important: the meaning of the code. Unfamiliar or inconsistent code means you have to stop and check if it really does say what it seems to, or....

Agree a coding style, and use it. Ideally, have a tool that will apply your agreed style.

Martin Ankerl

Posts: 9
Nickname: sunitram
Registered: Mar, 2005

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 8:53 AM
Reply to this message Reply
> I've come to believe that having a coding style is
> important, but enforcement is not:

I have to disagree here. For the java projects I work with I have created Unit Tests that execute PMD, Checkstyle and FindBugs. If a style checker fails, the build servers sends me an email. This way you get used to writing quality code, and you get the feedback very soon so fixing it is simple. My favorite check is cyclomatic code complexity, whenever this check fails I have to rethink and refactor the code into something simpler, which can be annoying but makes the code much more maintainable.

Also, with annotations you can disable style checks for specific code parts if there are good reasons to do so.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 9:56 AM
Reply to this message Reply
This is so much more entertaining than work on a Monday! I've been on a couple of code standard committees and I've found that after you settle on the big things, the rest gets you more trouble than it is worth. Everybody has their own style and to use Bill's variable declaration (columns vs. single space) as a good example, I don't find a big difference in either one. The columns are slightly easier to read, I guess, maybe, but putting all those tabs or spaces in is a complete waste of time. If we had to do that sort of thing I would write some stupid little emacs macro or python script to "fix" my code after I was done with it.

In my practical experience, after you've covered whitespace, brace alignment and variable naming conventions, the rest will cause you endless headaches. Those things can get easily fixed by a good refactoring tool or by firing off a simple script in your favorite text crunching language, which makes me think they are good candidates for code style.

This gets compounded if you are working on products that have pieces implemented in multiple languages. I've worked on projects that have been 3 parts C#, 1 part VB-something and 2 parts C++. Each language has its own standards and issues and differences that make any one set of conventions hard to follow or enforce. Should I bother putting in a preference for if (p != NULL) over if (!p) in the standard since it is C++ specific? What about forcing VB to use Option Base 0? Do I create separate standards for each language? What about the poor schmuck (me...) who actually has to follow the standards for all 3 since he has to work in all 3 languages?

This gets further compounded by trying to add new standards to legacy code bases. Do you reformat and "fix" the entire existing code base before doing any new work? Do you just write the new pieces using the new standards and leave the old code alone from a stylistic point of view? Do you make an effort to update code as you happen to be in it?

And now, since I'm late to the party, to reply to a few points in no particular oder.

> > I've come to believe that having a coding style is
> > important, but enforcement is not:
>
> I have to disagree here. For the java projects I work with
> I have created Unit Tests that execute PMD, Checkstyle and
> FindBugs. If a style checker fails, the build servers
> sends me an email. This way you get used to writing
> quality code, and you get the feedback very soon so fixing
> it is simple. My favorite check is cyclomatic code
> complexity, whenever this check fails I have to rethink
> and refactor the code into something simpler, which can be
> annoying but makes the code much more maintainable.
>
> Also, with annotations you can disable style checks for
> specific code parts if there are good reasons to do so.

As long as you can disable it when the need arises, great. I think you need to be careful about code passing the style checker being quality code, though. After all, would you consider trying to ware a pear of shoes? Did you comb yore hare this mourning? Those pass spell checkers well enough but are, well, silly.

>Things like bracket placement and blank lines should never be an issue because, these days, no one should be writing methods of more than a dozen lines; and in small methods the distractions of style differences are minimised.<

This is in direct contradiction with studies Scott McConnell cites in Code Complete. Personally I think artificially shortening routine length to fit some prescribed notion of the right number of lines will hurt more than help your code. I try to keep functions short but 12 seems to be a very small arbitrary number to use as an upper bound. Pages 173 - 174 of Code Complete, second edition contains a good discussion about routine length. The optimal size, for a variety of reasons, according to Code Complete seems to be about 10 times your desired maximum.

>I wonder if the tab or spaces intent war has over?<

Nope. It still rages on. There is an uneasy truce in python land since whitespace is significant in python, but even there the occasional battle flares up from time to time.

>As for how granular it should be, that's simple: make it as granular as needed, without spending too much time on it. Start with a basic policy everyone agrees on, and as soon as an issue arises, resolve it by adding a new rule.<

Given how personally some people take style, this is anything but simple. I've been on a couple of code standard committees and after you agree on the big things like use of spaces, variable names and brace alignment, it all hits the fan.

I think the most effective coding style policy is short and covers few items. In fact, if it is that important to you, I would talk specifically about your code style policy during interviews. Chances are that the more items the interviewee jives with in your code standards, I think the better they will fit your organization. After all, code is an expression of thought (probably the reason people take coding style so personally) and if their expression fits your predetermined idea of 'good' code, I think you have a pretty good indication that they may be a good fit for your organization, all other things being equal.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 12:00 PM
Reply to this message Reply
> The goal should be for any programmer to feel equally at
> home in any part of the code base, which means that code
> written by one programmer should be impossible to
> distinguish from code written by another programmer.

Several comments have said similar - that different code styles hinder collective code ownership. I just find this hard to believe.

The fact that some unfamiliar 3rd party open source library is used often hinders, a different take on "what is OO" often hinders, a poor design choice (like using a Bubble Sort, like using every pattern in the book to show off that you just read it) often hinders, but relative to those the placement of spaces in a line is just, well, trivial. If your programmers are seriously confused by bracket placement, they aren't very good programmers.


As for complexity measures, they are useful, but certain methods just don't fit. For example, a typical Java equals() method is inherently complex, even before it gets to do any real work!

io nous

Posts: 2
Nickname: ionous
Registered: Jul, 2007

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 12:52 PM
Reply to this message Reply
i think there are some bits of style important to constrain and while there are other bits that are not.

in terms of overall policy, for instance, i think throughout a given project you *must* have tab/space consistency and you *must* control method and class naming conventions. mixing conventions in those areas can lead to formatting chaos.

at the class level all member names should follow the same conventions, and at a method level all local variable names should be consistent. ideally there is global consistency, but it doesn't have to be mandatory like spacing, class, and methods.

comment style, bracing style, line divisions, and vertical whitespace seem the least important; providing guidelines rather than rules on these fronts seems best.

the golden rule of formatting: "keep the formatting of the file you are editing in the format style you found it" can be a good rule to foster harmony among co-workers who prefer conflicting styles.

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 2:10 PM
Reply to this message Reply
> > If programmers on my team can't adhere a style without
> > having to have their wrists slapped by some tool or
> > enforcement police, it's likely there are more serious
> > issues lurking that will bite the team far worse than
> > misplaced curly braces or indentation errors.
> >
> Thanks for pointing to that. In your blog you mention
> something Frank and I were talking about yesterday, which
> is the difficulty of seeing real code changes via version
> control diffs if you've got a bunch of format changes in
> there. We were thinking that maybe part of our policy
> should be that if you need or want to make formatting
> changes to a file as well as real changes, do the
> reformatting first, test, and check that in, then do the
> real changes, test, and check that in separately.

This is exactly what we do. Formatting changes are checked in separately.

I still occasionally sneak in a change or two that affects one or two lines, but nothing major.

If the formatting change will obscure or confuse the readability of the code change, we check it in separately. When it doubt, we check it in separately.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 4:34 PM
Reply to this message Reply
> If your programmers are seriously confused by
> bracket placement, they aren't very good programmers.
>

I agree completely. I've never understood how programmers who can handle complex pointers declarations in C++ are going to be challenged by a variation in bracket placement.

Coding conventions make a great excuse for anyone who doesn't want to actually wade through a method's logic during a design review to see if there are any functional problems. Instead they can "contribute" by pointing out little violations in the standard.

It's also been my experience that the conventions used aren't created as part of a team effort, but rather by management or the most aggressive control-freak on the team. If it's a team effort, why not have the team develop the standards?

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 5:01 PM
Reply to this message Reply
> > If your programmers are seriously confused by
> > bracket placement, they aren't very good programmers.
> >
>
> I agree completely. I've never understood how programmers
> who can handle complex pointers declarations in C++ are
> going to be challenged by a variation in bracket
> placement.
>

Well, the coding standards aren't for those folks for one thing. For another, I think the goal is to completely eliminate as much friction as possible. Personally, I've become a brace nazi because code like this

if (myBool)
doItNow();

almost invriably gets updated and needs the braces anyway. I'll always, always type
if (myBool)
{
doItNow();
}


just to eliminate any possible ambiguity. That is one thing that most of the experienced coders I've worked with agree on and it has made it into every code standard I've ever been a part of. The only fighting I ever got on it was from either young and inexperienced developers or people that have been working alone for most of their career.

> Coding conventions make a great excuse for anyone who
> doesn't want to actually wade through a method's logic
> during a design review to see if there are any functional
> problems. Instead they can "contribute" by pointing out
> little violations in the standard.
>

That drives me nuts, too.

> It's also been my experience that the conventions used
> aren't created as part of a team effort, but rather by
> management or the most aggressive control-freak on the
> team. If it's a team effort, why not have the team develop
> the standards?

I've been a part of such a process, which is why I think the standards need to be very focused on the few items I mention above. Too many standards make everybody unhappy.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: What's the Most Effective Code Style Policy? Posted: Jul 16, 2007 10:06 PM
Reply to this message Reply
ASCII art code is a very bad idea for two reasons:

1) Some developers like to use proportional fonts, and to them, the code will be hard to read (which is exactly how the code appears in the forum, by the way).

2) The slightest refactoring will mess everything up, forcing the user to do manual editing of the refactoring. Which is exactly what refactoring is supposed to avoid.

--
Cedric

disney

Posts: 35
Nickname: juggler
Registered: Jan, 2003

Re: What's the Most Effective Code Style Policy? Posted: Jul 17, 2007 5:45 AM
Reply to this message Reply
>> If your programmers are seriously confused by
>> bracket placement, they aren't very good programmers.
>
> I agree completely. I've never understood how programmers
> who can handle complex pointers declarations in C++ are
> going to be challenged by a variation in bracket placement.

Itsnotaboutwhethertheycanreadthecode,
itsmoreaboutmakingiteasyforth em.
theyrebusypeople,
andyouremakingtheirlivesmoredifficultbyinsistingonyour
'ri ght'totwritecodebadly.
ifyoureacoderyoureawriter,
andyouoweyourreadersenoughtoma keyourcodereadable,
dontyouthink?

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: What's the Most Effective Code Style Policy? Posted: Jul 17, 2007 10:18 AM
Reply to this message Reply
> >> If your programmers are seriously confused by
> >> bracket placement, they aren't very good programmers.
> >
> > I agree completely. I've never understood how
> programmers
> > who can handle complex pointers declarations in C++ are
> > going to be challenged by a variation in bracket
> placement.
>
> Itsnotaboutwhethertheycanreadthecode,
> itsmoreaboutmakingiteasyforthem.
> theyrebusypeople,
> andyouremakingtheirlivesmoredifficultbyinsistingonyour
> 'right'totwritecodebadly.
> ifyoureacoderyoureawriter,
> andyouoweyourreadersenoughtomakeyourcodereadable,
> dontyouthink?

And I thought I was the only one that had a gift for taking blanket statements to their illogical conclusion.

Nice!

Flat View: This topic has 43 replies on 3 pages [ « | 1  2  3 | » ]
Topic: What's the Most Effective Code Style Policy? Previous Topic   Next Topic Topic: Pardon My French, But This Code Is C.R.A.P.


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us