I do like the idea of storing the source code in some canonical form so diffs work, but showing it in the IDE in the programmer's preferred form. That way I can ignore the code style Nazis.
That said, the only bugs I can ever remember being caused by coding style are due to my lazy propensity to avoid {}s for one line if statements, plus accidently typing an extra semicolon
if (foo.isSpecial()); // this ; is an error handleFooIsSpecial();
Seriously, please cite examples of how much time you spent fixing bugs due to trivial white space and bracket placements. That's what IDEs are for - click on a curly bracket to see where it ends.
Then compare to how much time we spend arguing about code style and generating ponderous guideline documents, whose main purpose (as somebody else mentioned) is to facilitate code reviews that don't address any real issues but just look at bracket placement.
So long as everybody runs some sort of basic formatter so that the indents and brackets are lined up in a reasonable manner, why don't you just learn to live with each other's code style? I really really don't care if you put a whitespace before your opening parentheses on a for statement. I really really don't care anymore if your fields start with m, m_, or whatever. If any of our "expert" programmers are truly grieved by this, as the original post suggests, they are petty tyrants, not experts. Grow up and get over yourselves.
Next, are we going to enforce color conventions for syntax? Cause when we pair program, if one guy has a black background and horrid bright text colors, (hmm, are my predjudices coming through??? :-) and another has the normal white background, is that an issue worth regulating at your project, and dozens of posts on Artima? No, you grow up and live with it and worry about important things.
> Seriously, please cite examples of how much time you spent > fixing bugs due to trivial white space and bracket > placements. That's what IDEs are for - click on a curly > bracket to see where it ends. > > Then compare to how much time we spend arguing about code > style and generating ponderous guideline documents, whose > main purpose (as somebody else mentioned) is to facilitate > code reviews that don't address any real issues but just > look at bracket placement.
Well, I spent a good amount of time debugging a problem where some critical code had been put in an if(debug) block. It always worked when debugging was turned on.
But it's not really that this causes bugs that's the problem. It's that it make it difficult for others to understand. We were reviewing some COBOL not too long ago where the developer hadn't used indention for a large set of nested if statements. We basically looked at it for a few minutes and realized we could not figure out what it was doing without reformatting the code.
In the case I gave before where indention was used inappropriately, it almost caused a serious problem because I misunderstood what the code was doing in the progress of trying to make a change. The only thing that saved me was that I got so fed up with the sloppiness of the code I used a code formatter and did some other cleanup. It then became clear that the code wasn't nested at all.
Personally, I'm comfortable enough in Java that I can read code written in pretty much any reasonable style with ease. But if we were talking about another language, it might not be so easy. I think people can get a little control-freaky on the code style thing but a general consistency does make maintenance and debugging a lot easier.
> Completely unimportant. So long as you haven't done > anything outrageous like obfuscated C code, it's gotta be > by far the least important aspect of code quality. Well > named variables, DRY, clear intentions, adequate javadocs > and good design principles are vastly, vastly more > important than where the bleeping brackets go.
Ah, those things are all part of coding style.
Style is anything that doesn't affect the fact that something works. Can code work fine without javadocs? Can code work fine without properly named variables? Can code work fine without DRY? The answer is yes. Because the answer is yes, all those items are style concerns.
That's why they say "imperative style" and "functional style" and "OO style". Obvious "functional style" is different from "imperative style" by more than just superficial aspects of bracket placement.
> I do like the idea of storing the source code in some > canonical form so diffs work, but showing it in the IDE in > the programmer's preferred form. That way I can ignore > the code style Nazis.
Coding style has very little to do with how big your tabs are and where do you place your braces.
Don't confusing coding style with code formatting.
Formatting is only a small portion of style.
Of course calling people who care about style "Nazis" doesn't help you at all.
> Can code work fine without properly named variables? Can > n code work fine without DRY?
None of the discussion in this thread (so far) has anything to do with properly named variables and DRY etc. It has, for the most part, involved automatic formatting of white space, indents, and brackets. Therefore I'm guessing that most people don't DRY falls under "style". (Which, I admit, is a fairly loose term and subject to interpretation)
I'd welcome a discussion on how to try to enforce decently named variables, DRY, etc. So far, this is not the place.
I've used Jalopy about 2 years ago, plus still use the Eclipse formatter. They are fine for what they do, which in my mind is pretty unimportant.
IDEA has a nice feature of a checkbox setting to always run the formatter before checking in code. Very nice. Don't know why Eclipse hasn't stolen this. (At least, not that I know of, it's got so many options it could well be there somewhere)
I don't know of a tool to force variables to have meaningful names. It can force them to start with m_ (for example), but it would have to be pretty intelligent to differentiate m_zxcvbcas from m_numberOfPaddles. I guess it could at least see if any words from a dictionary appear. Hmm, maybe I should write this?
Our team used JCSC (or is it JSCS?) for a while. It tries to enforce more meaningful (IMO) code metrics. There are problems with it but to my mind it addresses more important issues than Jalopy.
> IDEA has a nice feature of a checkbox setting to always > run the formatter before checking in code. Very nice. > Don't know why Eclipse hasn't stolen this.
Horrible idea, I'm glad it's not in Eclipse by default. So you check in a file with a semantically important 1-character change -- add a missing comma, change = to == or something like that -- and when you check in, because of automatic reformatting, every 3rd line shows a change in the diffs with previous version. The important stuff is buried in noise, another programmer comes along with a conflicting change, sees all the noise of the reformatting and assumes there was no important change, checks in his version with the 1-character change reverted to the broken previous way. Ugh.
Always always keep the two kinds of changes separate. First, reformat, check in, then do the important change and check that in.
If everybody on the team uses the "autoformat" checkbox, it works great, cause the code you just checked out was also autoformatted - no spurious diffs.
> I don't know of a tool to force variables to have > meaningful names. It can force them to start with > m_ (for example), but it would have to be pretty > intelligent to differentiate m_zxcvbcas from > m_numberOfPaddles. I guess it could at least see if any > words from a dictionary appear. Hmm, maybe I should write > this?
Unless you supply the dictionary, I don't see how this helps. I can name my variable m_potPieSuperEgoMonkey if it's just any dictionary. If you supply the dictionary, it's be pretty time-consuming and still doesn't prevent people from misnaming variables: m_checkPopCheckPopCheck
Personally, these are things that I think are unimportant to check for automatically. These are things that really matter and only jackasses misname variables. Things like brace style where there is no common ground and it's easy to fall back into habits are too mundane to check. Any idiot can see the value of naming variables in a meaningful way. That's a management issue, not a technical one.
> None of the discussion in this thread (so far) has > anything to do with properly named variables and DRY etc. > It has, for the most part, involved automatic formatting > g of white space, indents, and brackets. Therefore I'm > guessing that most people don't DRY falls under "style". > (Which, I admit, is a fairly loose term and subject to > o interpretation) > > I'd welcome a discussion on how to try to enforce decently > named variables, DRY, etc. So far, this is not the place.
I was the first to reply and when I replied, I understood the term "style" in a very broad way, as in "functional style" vs. "imperative style", etc. I did not understand it as merely a formatting concern.
It's true that many people focus on formatting alone as the meaning of "style". That's very unfortunate. I wouldn't say this entire discussion is about formatting.
So, this discussion is whatever we make it. And I'm not making it about formatting. Are you? If you are, then you're willfully being obstinate (especially considering that you'd like to discuss those issues). You don't have to stop yourself from discussing what you want to discuss under the guise of "this is what this discussion is about". This discussion is not about anything in particular. Discussion are determined by participants. Participate please, if you want. I did. When I participated I talked about style as I understand it. You can knock me if you like, but not because "that's not what this discussion is about". That's not a valid knock.
> Unless you supply the dictionary, I don't see how this > helps. I can name my variable m_potPieSuperEgoMonkey if > it's just any dictionary.
It can't catch everything. It wont do natural language processing. But it can catch misspellings / typos. I'm a lousy speller / typer, and we have a lot of non-native English engineers at our company. There have been bugs or misunderstandings due to that. "potPieSuperEgoMonkey" could be parsed (using Java capitalization style) into "pot", "pie", "super", "ego"m and "monkey". All of those are correctly spelled English words, so it would pass the test. But if your variable (or method, we could expand the usage to that) was called "setPotPieSuperEgoMomkey()", it could flag momkey. If the variable were called "ppsem" (a style I use myself sometimes) it would be flagged as not "meaningful" and might get me off my lazy butt to change it.
One thing I used to do in my code was to group together all of the "trivial" accessors for a class, and write them on 1 line each. e.g.
// // Simple Accessors. //
public int getCol () { return col; } public int getRow () { return row; } public Foo getFoo () { return foo; }
public void setCol (int c) { col = c; } public void setRow (int r) { row = r; } public void setFoo (Foo foo) { this.foo= foo; }
Advantages: 1. Your eyes can gloss over this "trivial" "crap" and focus on the meat of the object. If you format according to most style guides and provide JavaDocs, each one of these will run about 10 lines of code, instead of one. 2. If this is all your class does, in other words, you've created a glorified data structure, (a style I deplore) at least you realize it right away. You can't say "gee, I wrote 60 lines of code and created this kick-ass object. You realize you accomplished very little. (Yes, sometimes you need glorified data structures, but usually they are a bad bad idea)
Disadvantages: 1. This is just too different that what everybody else does, and it fails all the automatic formatter tests.
> If everybody on the team uses the "autoformat" checkbox, > it works great, cause the code you just checked out was > also autoformatted - no spurious diffs.
That's kind of a self-eating watermelon though. If everyone uses autoformat, why do you need to use autoformat?
Besides, as others have pointed out, formatting is only part of the coding style, and as yet we don't have tools that can determine if anything more about identifiers than if they follow a simple convention like always starting with m_ or _ for member variables. No way to enforce meaningful, sensible names, which are what really count.
As I stated, if the important change is to correct a one-character error, it's easy to get lost in a sea of meaningless minutiae.
I believe the one liner formatting is largely a non-issue in modern IDEs/editors that support code folding and provide outline views (in Eclipse, besides the outline view, try hitting control-O in a java class).
The problem with formatting the code one way here and another way there is that it makes it hard to write parsing-auto-edit scripts, since you cannot rely on the code all being formatted in alike manner. This hit me once where I assumed that all ifs had braces (in Java world, that's a recommended way, as opposed to skipping the braces for one-liners).
Also the issue with what you call "glorified data structures" is that they are ultimately not. Why not? Because code is not something static. It's dynamic. What is just a glorified C struct today, becomes a class that delegates some of its accessors to another object tomorrow. That's the whole point behind accessors -- they leave the door open today to easy code evolution tomorrow.
It is sad that we have to type out accessors by hand in Java. It's too verbose and annoying. Java should be able to infer accessors, or at least, to provide an easy and pleasant notation for them.
But you know what? Maybe that's something we're learning as we go. Maybe we didn't know we would want that 10 years ago. I am using "we" in a very loose and poetic sense. :)
Flat View: This topic has 50 replies
on 4 pages
[
«
|
1234
|
»
]
Previous Topic
