• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Coding conventions

 
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I somehow ended up at a javaranch page with some style guidelines. It seems a bit at odds with Sun's conventions (and at some points premotes almost oppressive simplicity), but much of it is backed up logically (whereas Sun's is usually presented without further explanation).
Anyway, the javaranch page has driven me to reconsider my style (which developed mostly from books).
To do this, I'd like to see some other people's thoughts on the subject. Does anyone know of a project or other sort of organization which has an interesting style guide available on the web?
I'd also be interested to hear any isolated suggestions that wouldn't occur spontaniously to a person (like the convention in Refactoring of naming instance variables with an underscore first).
What are you careful to do (or to avoid) and why?
 
Ranch Hand
Posts: 2676
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This probably isn't what you had in mind, but I will post it anyway. coding conventions
 
Sheriff
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Matthew Phillips:
This probably isn't what you had in mind, but I will post it anyway. coding conventions


Thank you -- I'd lost that link -- it cracks me up.
I think these are my favorites:
3: Creative Miss-spelling: If you must use descriptive variable and function names, misspell them. By misspelling in some function and variable names, and spelling it correctly in others (such as SetPintleOpening SetPintalClosing) we effectively negate the use of grep or IDE search techniques. It works amazingly well. Add an international flavor by spelling tory or tori in different theatres/theaters.
8: CapiTaliSaTion: Randomly capitalize the first letter of a syllable in the middle of a word. For example: ComputeRasterHistoGram().
12: Underscore, a Friend Indeed: Use _ and __ as identifiers.
16: Names From Mathematics: Choose variable names that masquerade as mathematical operators, e.g.:
openParen = (slash + asterix) / equals;

Now for my real reply -->
The coding standards we use in HP Middleware are very similar to those listed in the JavaRanch Style Guide -- except our code is spaced by 3's rather than by 4's.
I've found that IntelliJ idea is VERY customizalbe when it comes to style/spacing -- it lets you control almost EVERYTHING -- spacing around control statements as well as spacing around methods... all sorts of stuff.
[ May 11, 2002: Message edited by: Jessica Sant ]
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This one is spectacular (although it doesn't apply to java )


C's Eccentric View Of Arrays: C compilers transform myArray[i] into *(myArray + i), which is equivalent to *(i + myArray) which is equivalent to i[myArray]. Experts know to put this to good use. To really disguise things, generate the index with a function:
int myfunc(int q, int p) { return p%q; }
...
myfunc(6291, 8)[Array];


I didn't know about this nice one either


JavaScript Scope: "Optimise" JavaScript code taking advantage of the fact a function can access all local variables in the scope of the caller.


Indeed, it isn't what I had in mind. Still, it does make some good anti-points.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A nice collection of different coding standards can be found here.
 
whippersnapper
Posts: 1843
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey, Jim, if this starts to verge toward being meaningful, is there a more appropriate forum this conversation should move to?
 
Michael Matola
whippersnapper
Posts: 1843
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
David Weitzman writes:
I somehow ended up at a javaranch page with some style guidelines. It seems a bit at odds with Sun's conventions (and at some points premotes almost oppressive simplicity), but much of it is backed up logically (whereas Sun's is usually presented without further explanation).
I have grown to really like the JavaRanch style conventions (with one exception).
Anyway, the javaranch page has driven me to reconsider my style (which developed mostly from books).
Same here. But keep in mind that I'm one of the students in JavaRanch's Cattle Drive, where we're required to use the house style for our assignments. Also keep in mind that I don't code Java professionally (yet!).
To do this, I'd like to see some other people's thoughts on the subject. Does anyone know of a project or other sort of organization which has an interesting style guide available on the web?
There are several Java style guides on the web. I'll try to dig out some links and post them.
I'd also be interested to hear any isolated suggestions that wouldn't occur spontaniously to a person
(like the convention in Refactoring of naming instance variables with an underscore first).
I don't like it. One problem with this is that I've run across an opposing convention -- naming all parameters with an initial underscore.
The best advice I've seen along these lines is that if your method is so long or confusing that you can't tell at a glance what are parameters, temps, or instance variables, then you've got bigger problems than just a naming convention can help with. Refactor the code until it's clear.
My chief rule for variable names is that they must be pronounceable. This sometimes makes for some longish names. I don't care. I type fast. I read a lot more code than I type. Someone once told me that if you can't read a variable name to someone over the phone and have them understand, the variable needs to be renamed.
There's an interesting convention from the Smalltalk community that you sometime see in Java code -- prefixing parameters with indefinite articles, "a" or "an." Since variables in that language are untyped, this naming convention helps you decode method signatures, so you have a better idea of what's getting passed in: anInteger, aDateRange, aCollection, etc.
Along those lines (sometimes in the same code), I've also come across instance variables prefixed with "the" or "its": theInteger, theDateRange, theFrame, itsCollection, etc.
At first I liked this and played around with using it. But then I started not liking it because it's too easy to fall into the habit (maybe only in Java?) of just calling everything prefix plus reference type (which is vaguely Hungarianesque), instead of naming the identifiers based on what they do in the code.
I've since rejected all these approaches in my code and just try to be as descriptive as I can with identifiers.
I'd also be interested to hear any isolated suggestions that wouldn't occur spontaniously to a person...What are you careful to do (or to avoid) and why?
How about some code examples that exhibit styles that I consider to be a crime against good taste and all that is beautiful in the world?
Look no farther than Sun for this one. To be fair to Sun, they don't use it all that much, and the code I'm quoting is documentation on how to use a class, and not actual source. But I've seen this technique all over the place in books and I think it's hideous.
From the documentation on how to use InputVerifier.

The idiom I'm refering to is lines (A) and (B): "else return false;"
Short version of rant -- why not just use the simple construction "return < boolean expression >":
return pass.equals( "pass" ) ;
It's by far the clearest way of writing this.
Long version of rant -- It doesn't bother me much that there are multiple returns in the original. What makes my skin crawl is the "else return false;" It's so ugly and pointless.
First off, I consider one-line if statements a crime against good taste. (Despite Fowler. Fowler has written some brilliant things and is one of my coding idols, but I can't bring myself to tolerate one-line if statements.) At its core, what is an if statement about? It's about the conditional execution of a piece of code. Well, elevate that piece of code to the status it deserves by making it a block (enclosing it in curly brackets) and putting the statement on its own line.

Also, in general, it's often a Good Thing if you can eliminate an else block as I've done here, if you're comfortable with the resulting implication that whatever happens instead of the if code (or in addition to if the if block doesn't return) is some sort of default behavior. (This is similar to Fowler's refactoring "Replace Nested Conditional with Guard Clauses," but not exactly. I'd be happy to illustrate my take on that refactoring in another post if there's interest.)
In the both the "else return false" and my example, the else keyword is completely unnecessary, since the if statement returns if true. So why does the coder keep the "else" in the original "else return false"? I bet it's because it's very easy to overlook the "return true" in the one-line if version and assume that the method always returns false and the coder is uncomfortable with the inadvertent implication that the method always returns false.
if ( pass.equals( "pass" ) ) return true ;
return false ;
Incidentally, if you want to empasize returning false as a default, then make that very clear in the code by setting the default at the onset. This might be a time when I'd side with the "only one return per method" crowd.

And if you want to give equal weight to the the two conditions, do something like this

But in the general case, why not use the clearest idiom of them all (which also happens to satisfy the "only one return per method" crowd) and avoid the awful "else return false":
return pass.equals( "pass" ) ;
Anyhow, that's my style rant on "else return false." I have a few more where that came from.
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Jim, that's just the sort of thing I'm looking for. Now if only IE would stop crashing...
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Now if only IE would stop crashing...
Sorry, that one's outside my purview.
Hey, Jim, if this starts to verge toward being meaningful, is there a more appropriate forum this conversation should move to?
Yeah, now that you mention it I guess I should move it to Java in General - let's say Intermediate. See you there...
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Matola:
The best advice I've seen along these lines is that if your method is so long or confusing that you can't tell at a glance what are parameters, temps, or instance variables, then you've got bigger problems than just a naming convention can help with. Refactor the code until it's clear.


I fully agree. For the same reason, I strongly disagree with all the points in the "Constructs to Never Use" part of the JavaRanch conventions. None of these should be an issue in properly factored code, IMO.
I really like "4.2 - Self Documenting Code", though
Regards, Ilja
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know this thread is a little over a year old, but I just recently got into Java. I'm constantly studying coding style and portability along with general good coding practices, algorithms, and performance tuning. I'm a long time C programmer, and mostly studied all algorithms and coding style in C.
However, Java syntax isn't very different from C or C++. When I read the coding standards on javaranch, I was amazed by some of the suggestions. For instance, "Don't use continue/break"?!? Continue and break are most definitely needed in loop constructs. Especially if you're thinking about performance! I'll openly admit, continue and break are highly misused at times, but they are still 100% necessary. The reasoning behind not using them at all was not reason enough to stop using them. If people are misusing continue/break, they seriously need to fall back to common coding. I'm talking about going all the way back to the "Basic programming" course!
do/while is also a needed construct. I think maybe the author behind the coding standards didn't fully understand the idea behind a do/while loop? In a do/while loop, you always want that loop to execute at least once. Now, this is great when you have a complex loop that depends on a complex condition, but you want it to execute at least one time BEFORE testing the condition. In the situation the coding standards suggest, you must test the complex condition FIRST then go into your loop body, then RETEST that condition. If it's a highly complex condition that involves a good bit of time, you've just tested that condition twice! Wow, you better hope your boss or your application doesn't depend on time constraints or performance in this case! Not to mention since we took out the useful 'break', we can't even break out of this loop successfully in an attempt to save processor time and performance issues... We must complete the entire complex loop going through each check! Heaven forbid if we want to 'continue' back to the top of the loop to save time and performance in order to recheck that condition to 'break' out of the loop. You're stuck wasting time and performance with these standards!
Some may say that you have to sacrifice some performance in order to keep code readable and stable. Sure, I buy into this theory as well. However, do/while, continue, and break are 3 very well known and very easily understood areas in programming. You cannot cater to newbies when you program. If that was the case, we'd all be writing useless software that prints "Hello, World!"... The newbies are supposed to LEARN how to program, and they will. They will learn how to use a break, continue, and most definitely, do/while! If they have not learned any of these, we shouldn't cater to their lack of knowledge, but they should reevaluate their programming skills and peek inside of their books when they see a do/while...
Basically, code readability is important. It's a great thing to write code that is readable. You should practice good style all of the time... However, it is absolutely absurd to remove needed keywords or constructs in order to achieve this. Even in the world of C/C++, goto is needed on very few occasions and can be written in a VERY readable manner. However, you have the die hard "I hate goto" subscribers out there. It's quite senseless to remove goto completely, when goto can save your life when it comes to performance and actually maintain good readability!
However, we're talking about Java, and I say, please DO use continue, break, and do/while loops. Just use them in the correct sense and moderation!
Put it this way, it's a good idea to assume that if you have about 10 or 20 reasons to 'break' out of a loop, you need to really rethink your code design. Same with continue. I generally only have use for a 'break' or 'continue' once or at the most twice in my loops. If I notice that I'm using it more, I redesign my algorithm! It's getting a bit crowded and more than likely, I'm overdoing the functions purpose anyway!
With do/while loops, think about the purpose of them. If you absolutely, under ANY CONDITION need to have a loop execute at least once, use do/while. That's why it's there, people! If you don't understand the purpose of a do/while, go back and read your books again! do/while is in almost every single high level programming language. If you can't grasp it's use or the idea behind it, you aren't coding correctly in the first place... because it's a common loop and I feel it's safe to bet that you are messing up in A LOT of other areas as well.
Another few points, I don't agree with the 120 character line size... That's WAY too much. I feel as if the person that wrote this is definitely a windows programmer that always uses very large IDE's... You must think outside of your box when you're writing standards for style... You can't just think "well, everyone uses a GUI text editor..." Not everyone does! Us Unix folks use VI. Which, when used from a terminal on a 1024x768 screen, isn't going to enjoy a 120 line piece of code! A good rule of thumb here is to not go over 90 for your line buffer. 80 is the STANDARD. On a common terminal, 80 characters is the width. So if I have to telnet or ssh into your box and use a terminal based text editor, I'm screwed with your 120 character lines... Talk about ugly code!
Also, let me mention in this long winded reply, that method design isn't really covered well. Another good general rule is method size. I maintain a lot of code here at work, and I see method/functions spanning up to 9,000 lines!!! No, I'm not kidding. I had to break up a function in C that spanned 9,010 lines in a file. That is absolutely 100% improper, unreadable, unnecessary, ugly, stupid, and more than likely worthless. For myself, I usually consider that if I'm going over 100 lines in a single method/function, I'm starting to lose the purpose of that method/function. I've written method that have been up to 120 lines, but even after I wrote it, I went back over my code and made sure that I couldn't break up that method into maybe one other method... I think a method over 200 lines can always be broken up into smaller more manageable methods.
A method should focus on ONE purpose and ONLY one purpose. For instance, the method shouldn't calculate how long it takes to get to the moon and back and how old your grandmother was when she got her first kiss and then return X, it should simply do what it has to do to get X and return it! Usually, if your methods are exceptionally long, you should be breaking that single method up into more methods that have a single purpose. The exception to this rule is a method that uses a switch() construct. Switch constructs can get long, but are highly readable...
Another good way to tell if you need to break up your methods is to count the number of variables you're declaring and using. If it's over 8, it's a good idea to start to think about your code. That 9,010 line function that I rewrote had about 50 defined variables in it... That's just silly.
Anyway, I'll be quite happy to give more suggestions. I spend A LOT of time studying these areas of programming since I do a lot of code maintaining at my job... Algorithms, Style, Performance, and Portability are my specialties!! I can suggest good books on it, and also give pointers... If you disagree with my style, and have a good reason, I always love to hear the reasons... I'm quite open to changing my opinion, if someone can prove my ideas obsolete!
Thanks for reading this long response that is a year late!
[ July 21, 2003: Message edited by: Geekoid Programmer ]
 
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Geekoid Programmer
Nice post. Alot of good thoughts. Of course in most shops you get NO say on the coding style. The JavaRanch coding style we set up so that the Cattle Drive programmers would have a style to follow. The issue there is whether or not they can follow a style guide. As a rule when you change jobs, you have to adapt to the new places style guides.
At any rate,

Welcome to JavaRanch!! Please change your name to be compliant with JavaRanch's naming policy. It should not be obviously fictitious.
Your displayed name should be 2 separate names with more than 1 letter each. We really would prefer that you use your REAL name.
You can change your name: here.
Thanks,
Cindy
 
Dean Jones
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cindy,
Thanks. I changed my name. It seemed as if when I was signing up, it would not let me use my name. It said it was already in use. Not my login name, but my real name. For when I changed my real name to "Geekoid Programmer", everything went through fine.
I know that in most shops or jobs you get no say in coding style. However, my beef with that is that 90% of the coding styles out there are garbage. They neglect to cover the essential areas of coding style. They also neglect to actually look into if their coding style will work properly! For instance, the 120 character line buffer isn't going to work for every programmer on the team. You have to stop and think about potential programmers on the team. More than likely, the next team member isn't using the same IDE or editor you are. Unless you're demanding the same editor or IDE be used, you have to take into account the differences that exist with the multiple text editors. 80 characters has been the common standard for over 30 years... I've seen and heard of up to 90 (on one occasion 100), but I have never seen someone suggest 120... For me, and a lot of other programmers, a 120 character line would almost wrap twice!
Things such as indenting, brace placement, and such can be up to the original author or team leader. Since these areas are really specific to the style of the code and not dependent upon the tools used, but the programmer. Any text editor allows you to use the tab key. :-)
However, other areas need to be addressed with diversity in mind. I've designed a few style guides (security and portability guides too) for some of the Open Source projects I've been on, and also at work as well. Being that a good coding style can significantly help with code maintainance which in turn can lead to more stable applications, coding style actually pretty important.
As far as adapting to a new jobs coding style, that is generally true if you're shy and don't speak up. Most of the places I've worked for have no problem with changes to the style guide. As a matter of fact, we're changing our style guide at my current place of business due to how poor it was previously. The reason it is being edited is because someone (Not on my team) spoke up and recommended a better guide. Coding style is an area that a lot of people get set in their ways on, but if you can prove to them that a different guide would be more effective, usually people are open to changing their mind. Especially if you can prove to your boss that it will ultimately help in productivity! Not to mention a possible raise or promotion! (yeah, not likely... but we can all dream.)
Regardless, I still highly suggest that anyone who writes a convention or guide actually think about the language they're writing in, the people who may attend the project, the diversity that exists and also the benifits of the actual convention or guide they are writing. Otherwise, it's kind of pointless to write a convention that isn't going to help the project. The point of the convention is to organize the project, not keep it disorganized and make it harder for programmers to actually code!
Anyway, thanks for the welcome.
Dean
 
Cindy Glass
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You know - amazingly enough in 20 years in this business I have NEVER met anyone who actually WROTE a style guide , Only folks stuck following them .
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've written them for a half dozen languages over the years. Java is rich enough that the style guide is pretty big; I just bought Elements of Java Style and published a few extensions and exceptions.
I like it that most Java IDEs have pretty formatters. I use the ones in VAJ and Forte CE all the time. There are tools out there that go into naming standards and other details. Haven't tried them yet, but I would probably like them.
 
Dean Jones
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, fortunately, there are people around that actually do write the style standards and other standards... I mean, you have to know that there are real live humans that wrote the ISO standards!
At my company, we follow strict ISO standards and get monthly / yearly audits. Which, can be a big pain sometimes... However, I think along with style guides should be portability and security guides... and on many occasions, documentation guides!
 
Dean Jones
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
I like it that most Java IDEs have pretty formatters. I use the ones in VAJ and Forte CE all the time. There are tools out there that go into naming standards and other details. Haven't tried them yet, but I would probably like them.


Yeah, I use VIM. It's not an IDE, per-se, but a very nice text editor. They actually have GVIM for Windows. So, when I do have to use Windows, I use GVIM for my coding. It does some neat customizable syntax highlighting... Which, I find extrememly useful. VIM will let you know when you're missing opening or close brackets, parens and what not... It will highlight the unclosed paren/bracket in red until you close it off... That's helped me out a lot when it came to debugging source that wouldn't compile.
It also works extremely well with 'make'. Being that when you compile your source with 'make' from within VIM, if a compile error pops up, VIM will take you to that file and actual line number! That's pretty hot, I think.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Looks like you've run afoul of Dean Jones Jr. Unless that's actually you. The most frequent source of name collision at the ranch is people who register, forget about it, and register again. But apparently, that's not the case here. So, glad you got in and were able to change your name back later. (That's sort of a security hole, but it works out well for us here.)
As for your main points - well, I pretty much agree. I think that break and continue are natural, obvious choices in certain situations, and code becomes needlessly convolutied if we prohibit them. I'd include mutiple method returns in this category as well.
As for do/while - to be honest, I can't really remember if I've ever had occasion to use it in real code; it always toruns out I want to perform the test first rather than last. Actually I often find I want to perform the test somewhere in the middle, and so I hve to figure out how to reorganize it, or use a while (keepGoing) type of structure. But the latter usually ends up rather convoluted. But, while I've had no real use for do/while so far, I have no problem reading it if someone else uses it, and see no need to ban it.
I also agree about an 80-char limit. On my laptop, I've got my eclipse windows set up just right so I get the full 80-char width I need and also have a number of other useful windows up. If code goes over 80 chars, I have to reorganize, and give up some other nifty window, which annoys me.
I agree with most of the other points too. Though for the most part those aren't things that contradict the style guide, just things that weren't covered. The Chicken Coop guide is designed to be pretty lightweight, on the theory that this increases the chance that people actually read the whole thing. Personally I'd be inclined to go into more detail on many of these points, but I must acknowledge that there's some virtue to be found in brevity too. I'm just not very virtuous, myself.
 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Matola:

And if you want to give equal weight to the the two conditions, do something like this

But in the general case, why not use the clearest idiom of them all (which also happens to satisfy the "only one return per method" crowd) and avoid the awful "else return false":
return pass.equals( "pass" ) ;
Anyhow, that's my style rant on "else return false." I have a few more where that came from.[/QB]


Your last example is great for simple logic. Your former example works even in complicated logic, and I use it often. The nice thing about it is that you can "assume" the code is going to hit the bottom of the method (which IMO is a good thing). This is something that I grew accustomed to during my years with Delphi (OO Pascal)... where you didn't return anything. You assigned it to "result" and when the function ended, that's what was passed back. Code that "ended all over the place" was very obvious in that language (analogous to having multiple returns in Java).
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"else" after "return" is completely redundant anyhow, and for no reasonable reason infuriates me:

Sorry, maybe it's just me.
 
Trailboss
Posts: 23773
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I started off over 20 years ago doing BASIC and assembly. I GOTO and JMP were the mainstays. And then I went to college and learned Pascal. Anything resembling GOTO or JMP was verbotten. After a while I saw the wisdom in it and followed the professors lead. Of course, there was the rare occassion when a GOTO was the cleanest way - for me, this was always around exception handling.
break, continue, exceptions and several other constructs in java are really nothing more than fancy words for "GOTO" - the command that only bad spaghetti code BASIC hacks depend on - at least that is now my conditioned response
When I'm in somebody else's code and it needs to be enhanced/fixed/whatever, I find that the GOTO replacements typically hinder refactoring. For example, suppose you try to move a block of code out of a for loop into a new method. And DAMN! Somebody stuck a return right in the middle of it! Well that sure makes refactoring a bit awkward! Same goes for continue or break.
It is simply my opinion that these constructs lead to code that is less maleable (more brittle). It is possible that in a profiling step you could discover a significant performance boost by using one of these constructs. If it's speed critical code, such a change may be worthwhile, but would probably be insignificant. These days I think the value of readability and maleability far outweigh performance.
 
author
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Interesting that there is an almost identical / parallel thread happening in the beginner forum as we speak!
Can the two be merged?
 
Sheriff
Posts: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
They seem different enough to me (although they're both about code style) that I think I'll leave them both, separate.
 
reply
    Bookmark Topic Watch Topic
  • New Topic