The Artima Developer Community
Sponsored Link

Weblogs Forum
How Important is Coding Style, and How Do You Enforce It?

50 replies on 4 pages. Most recent reply: Jun 1, 2007 3:29 PM by Elnar Hajiyev

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 50 replies on 4 pages [ « | 1 2 3 4 | » ]
disney

Posts: 35
Nickname: juggler
Registered: Jan, 2003

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 4:05 AM
Reply to this message Reply
Advertisement
My opinion is that coding style is a significant issue *because* it's so unimportant! A *consistent* coding style allows us to ignore it, and concentrate on reading and understanding the code, which is what matters. The actual coding style adopted doesn't matter; consistency does.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 6:49 AM
Reply to this message Reply
> Maybe the next generation of IDEs will completely divorce
> the saving format from the display format and also the
> diff could work on the AST instead of on the text. The
> refactoring stuff in modern IDEs is a step in this
> direction - so we can only hope :)

This is something that I've been wanting for years. There was an attempt to create an XML based version of Java that would have addressed this, separating the storage from the display. The concept is great but the addition of XML was ill-advised.

Really, all you need is to define a canonical style (something readable in case you need to look at the raw files in a text editor) and define transformations from that style to each developer's preference.

You would automatically get very uniform code and every developer gets to see things the way they want it.

That would deal with the 'superficial' issues but I think the rest is still important. I think it's especially important to enforce style rules with contractors because I've seen too many code muggings by people who don't have to care about maintenance or be around when people see what a mess they made.

And code-style can be important. In Java, for example, there are things that you can do that are really problematic for maintenance and understanding of the code:
if (condition1)
   doSomething();
   
   if (condition2)
      doSomethingElse();
 
       if (condition3)
           doYetAnotherThing();


I've seen actual production code that was written this way. This is superficial but really confusing when reading the code over, especially when it's buried in a 500 line method with half the code commented out. It's also unclear what the developer's intention was originally.

On of the things I really like about Python is that it treats indention as syntactically significant. It seemed stupid at first but there's no chance you can end up with confusing things like the above.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 6:55 AM
Reply to this message Reply
> My opinion is that coding style is a significant issue
> *because* it's so unimportant! A *consistent* coding style
> allows us to ignore it, and concentrate on reading and
> understanding the code, which is what matters. The actual
> coding style adopted doesn't matter; consistency does.

I kind of disagree with the 'I'm OK, you're OK' argument about style. I think you can make really good arguments about why certain styles are more illuminating than others. For example, you can could write Java code without any indention at all. I doubt there are many developers that will seriously argue that this style is just as good as any other.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 9:17 AM
Reply to this message Reply
> > Maybe the next generation of IDEs will completely
> divorce
> > the saving format from the display format and also the
> > diff could work on the AST instead of on the text. The
> > refactoring stuff in modern IDEs is a step in this
> > direction - so we can only hope :)
>
> This is something that I've been wanting for years. There
> was an attempt to create an XML based version of Java that
> would have addressed this, separating the storage from the
> display. The concept is great but the addition of XML was
> ill-advised.
>

Yes, XML definitely sounds like an overkill.

IDEs already can auto-reformat code to adhere to a given set of style templates, but my problem with that is that they change the actual source code. I use the source control system to find what changes were made to code, and reformatted code totally messes that up. If I have diffs in every file in a package, and have to sift through what changes were just formatting changes, and which ones were substantive ones, that's just a huge waste of time.

Is there a way to make either CVS or Subversion more intelligent about diffs? A plug-in perhaps?

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: CruiseControl with CheckStyle Posted: Jan 31, 2007 9:20 AM
Reply to this message Reply
> CruiseControl* should run CheckStyle. The build should
> fail if CheckStyle fails.
>
> *or your favorite Continuous Integration server.

I'd be curious how many people actually do this, though. Yes, it would surely enforce coding style, but at the expense of inflating the integration server's red flag.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 10:00 AM
Reply to this message Reply
> Yes, XML definitely sounds like an overkill.
>
> IDEs already can auto-reformat code to adhere to a given
> set of style templates, but my problem with that is that
> they change the actual source code. I use the source
> control system to find what changes were made to code, and
> reformatted code totally messes that up. If I have diffs
> in every file in a package, and have to sift through what
> changes were just formatting changes, and which ones were
> substantive ones, that's just a huge waste of time.
>
> Is there a way to make either CVS or Subversion more
> intelligent about diffs? A plug-in perhaps?

I think that the wrong place to solve the problem. I don't think I was clear in what I was proposing (or rather hoping for). What the IDE should do is display the code in the developers preferred style but always maintain the actual source files in a canonical style. I would envision this canonical style being very uniform even in terms of whitespace and line wrapping.

Given that there are already code formatters that can do this, I can't imagine that one or more could not be modified to just be display and format in memory changes to the canonical style on the fly. Some changes in the basic design might improve performance but I doubt they are necessary to get a proof-of-concept together.

I was also going to say before to Howard Lovatt, that being the smart guy he is, maybe he could dig into the eclipse code and try to hack this out ; )

Steven E. Newton

Posts: 137
Nickname: cm
Registered: Apr, 2003

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 10:21 AM
Reply to this message Reply
All the issues with automated code reformatting generating confusing and useless diffs in the version control system have a fairly simple, non-technical, solution.

It works like this. When you are preparing to edit a source file to make some semantically important changes and the automated code-reformatter also wants to move things around, do the change in two steps. Step one: let the reformatter do its cleanup, make everything pretty, but make NO other changes. Check in the file with a comment like "Reformat changes only" to indicate that the code hasn't really changed*. NOW make your real changes as needed, run your unit tests, etc, and check in with the actual change message.

Result: The diffs between what you changed and the original source are clear and isolated, yet there is a record in the changelog of the reformatting, which can be compared to the prior version (if needed) to see what the formatter did.

The extra effort is minimal for programmers who are serious about enforcing a coding style, while the benefits of being able to differentiate real changes from reformatting (and potentially help in identifying programmers who are checking in code that doesn't meet the style guidelines) are manifold.

As a side note, I've come to believe that having a coding style is important, but enforcement is not. 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.

* Note that sometimes reformatting code, even though there are supposedly no changes, will in fact result in changed behavior, especially in languages like Python where whitespace is meaning full, but even in languages where whitespace is mostly ignored. Another reason it's good to have a clear record in the source control of only formatting change checkins.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 10:56 AM
Reply to this message Reply
> Is there a way to make either CVS or Subversion more
> intelligent about diffs? A plug-in perhaps?

I use one today: jacobe from tiobe (free for individual use), which plugs in to ExamDiff Pro ($35 from PrestoSoft) which plugs in to wincvs (free for all).

So long as "coding style" refers only to formating, then there never was an argument about this that held water. I prefer 3 space indent and never a tab and
foobar ()
{
}

Others may prefer some other. So what? If we're talking about syntax, then let's call method variables m_foo or whatever.

Formating does matter, in that read is what gets done, and we all have a scan sweet spot. There's no good reason to impose the Pointy Haired Boss' on the rest of us.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 4:17 PM
Reply to this message Reply
@James Watson,

Thanks for the complement.

Actually in my pet project, http://pec.dev.java.net/, I am interested in modifying and analysing source code, for the purpose of enforcing design patterns. One of the problems is that everyone uses different conventions and you need to deal with these when modifying source code. So I have thought of taking any old format and convention and converting it into a standard (canonical) form and modifying this. This canonical form would be great for a diff program or another program like Javadoc as well as my compiler (PEC).

However this is hard to do - I might not be up to the task :( Also I use Netbeans and in particular the Jackpot API in Netbeans to modify the source; so unfortunately an Eclipse plug-in is some way off :(

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 5:30 PM
Reply to this message Reply
> @James Watson,
>
> Thanks for the complement.
>
> Actually in my pet project, http://pec.dev.java.net/, I am
> interested in modifying and analysing source code, for the
> purpose of enforcing design patterns. One of the problems
> is that everyone uses different conventions and you need
> to deal with these when modifying source code. So I have
> thought of taking any old format and convention and
> converting it into a standard (canonical) form and
> modifying this. This canonical form would be great for a
> diff program or another program like Javadoc as well as my
> compiler (PEC).
>
> However this is hard to do - I might not be up to the task
> :( Also I use Netbeans and in particular the Jackpot API
> in Netbeans to modify the source; so unfortunately an
> Eclipse plug-in is some way off :(

I would really love to take a crack at this, even though I think I'd probably be getting in over my head but... I too am working on a side project and I've started way too many things without completing them.

But while we are talking about it, it doesn't seem to be that hard. Perhaps I am being a little naive but if you have a parser for Java, which there are quite a few, you should be able to break it down and write it out in whatever format you please, right? I assume (with no real knowledge about it) that this is what the code formatting in Eclipse does. The other thing is that it seems that you could cannibalize the Eclipse (or any other open-source) code formatter and make that code do this, if that code is reasonably well written.

I need this because I hate my current team's Java standards. I think it's important to follow the standard but it pains me greatly.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Jan 31, 2007 6:26 PM
Reply to this message Reply
@James Watson

A few things spring to mind:

0. I agree with you that there is nothing greatly wrong with the text representation of Java, so why bother with a XML version. You could use a rigorously formatted, right down to the very last space, form of Java as the standard representation. The source code formatter I use Jalopy could probably do that.

1. The reason that I am using Jackpot is that it builds upon the Compiler API that is part of J6. The Compiler API exposes the AST that the compiler generates, but for read-only. The Jackpot API extends (literally extends the classes) in the Compiler API and adds write methods so that you can now read and write the compilers own AST. It will also then write this AST back to the source file, or you can continue with compilation, or do both. Jackpot is unfortunately Netbeans only, but the Compiler API is any Java 6 JDK.

2. The Compiler API isn't designed for a pretty printer and would not be capable of representing white space to the extent a pretty printer's AST can, but it seems to me to be ideal for decoupling the formatting from the syntax. For example for: an intelligent diff, a naming convention enforcer, etc.

3. If you had tools that where not sensitive to layout the coding conventions could be much more sensible; they would concentrate on stuff like public method names should begin with lower case, public classes upper case, public names should be Camel Case, if blocks should always have braces, etc. And not worry about stuff that is private or about if the braces are on the end of the line or not, etc.

4. The difficulty with converting to a canonical form isn't so much that it isn't possible. The Jackpot API could probably do it. But there are so many variations it is difficult to be sure that you have covered every possibility. In the case of my PEC project I also want to go back to the source form and ideally would like to go back to how the original programmer wrote the code. EG suppose that the original code used an import and the canonical form eliminated this by using a qualified name, then I modify the code, then I want to convert back to the original form so I want to add back in the import statements (this is tricky to get right).

5. Switching topics, I work on projects that different programmers have different styles. We do as someone else suggested in this forum which is use you own favourite style. If you are working on someone else's code reformat it as you like it and if necessary do a commit that is solely for the purpose of changing format. This seems to work fine. But it would be nice if the IDE automatically did this when committing.

Marc Loxton

Posts: 9
Nickname: spoonchops
Registered: Feb, 2006

Re: CruiseControl with CheckStyle Posted: Jan 31, 2007 6:43 PM
Reply to this message Reply
> > CruiseControl* should run CheckStyle. The build should
> > fail if CheckStyle fails.
> >
> > *or your favorite Continuous Integration server.
>
> I'd be curious how many people actually do this, though.
> Yes, it would surely enforce coding style, but at the
> expense of inflating the integration server's red flag.

We do it where I am at the moment with luntbuild running checkstyle via ant coupled with checkstyle plugin in eclipse. Check the xml file into source control and make sure the same version of the same thing is always being run on the server as what's in everyone's browser. In that way it works quite well since we have a standardised dev environment.

disney

Posts: 35
Nickname: juggler
Registered: Jan, 2003

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Feb 1, 2007 1:22 AM
Reply to this message Reply
>> My opinion is that coding style is a significant issue
>> *because* it's so unimportant! A *consistent* coding
>> style allows us to ignore it, and concentrate on
>> reading and understanding the code, which is what
>> matters. The actual coding style adopted doesn't matter;
>> consistency does.
>
> I kind of disagree with the 'I'm OK, you're OK' argument
> about style. I think you can make really good arguments
> about why certain styles are more illuminating than
> others. For example, you can could write Java code
> without any indention at all. I doubt there are many
> developers that will seriously argue that this style is
> just as good as any other.

I was trying to focus on the important issue: code that is readable and understandable, and therefore maintainable. Of course there are coding styles which are less than optimal, such as no indentation at all, as you observe.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Feb 1, 2007 3:23 AM
Reply to this message Reply
I'm familiar with Emerson's quote, but I think the keyword here is "foolish". Consistency, in itself, is not a bad thing, and can be very useful, such as not having to learn to drive a car, any time you're going to drive a new car, and can instead focus on more interesting things.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How Important is Coding Style, and How Do You Enforce It? Posted: Feb 1, 2007 5:38 AM
Reply to this message Reply
> 4. The difficulty with converting to a canonical form
> isn't so much that it isn't possible. The Jackpot API
> could probably do it. But there are so many variations it
> is difficult to be sure that you have covered every
> possibility. In the case of my PEC project I also want to
> go back to the source form and ideally would like to go
> back to how the original programmer wrote the code. EG
> suppose that the original code used an import and the
> canonical form eliminated this by using a qualified name,
> then I modify the code, then I want to convert back to the
> original form so I want to add back in the import
> statements (this is tricky to get right).

Yes, if you got really deep into this, I can see how it would become tricky. I was really just thinking about brace-style and indentation mostly. I don't think it would be a good idea to mess with variable names and qualified names.

> 5. Switching topics, I work on projects that different
> programmers have different styles. We do as someone else
> suggested in this forum which is use you own favourite
> style. If you are working on someone else's code reformat
> it as you like it and if necessary do a commit that is
> solely for the purpose of changing format. This seems to
> work fine. But it would be nice if the IDE automatically
> did this when committing.

This can work but it just seems sloppy to me to have a lot of massive diffs in the source control. If you want to see what's different across many version, it's going to be messy. Even if you have a tool that ignores changes that are merely formatting, it seems messy.

Flat View: This topic has 50 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: How Important is Coding Style, and How Do You Enforce It? Previous Topic   Next Topic Topic: Regenerative Build Tools

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use