• Post Reply Bookmark Topic Watch Topic
  • New Topic

Please share your thoughts about Code Convention  RSS feed

 
Vandre Caetano
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the company I work in we are creating some sort of internal java code convention, and lately there has been some discursion about what is and what is not important, the most discursed topics where:

if a line should have more than 80 characters
if we should use ternary expressions
if a method should have more than 1 return (just a note: someone told me that its wrong to have 2 returns in OOP)


So I was interested in what other people think about those, what are your impressions about the java code convention, and if there are other things you also find important to keep your code more readible

Thanks in advance
 
fred rosenberger
lowercase baba
Bartender
Posts: 12564
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch!!!

In my opinion, it doesn't matter so much what you decide, as long as everybody follows it. No matter which way you go on any issue, SOMEBODY will think "that's the stupidest way to POSSIBLY do that".
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fred is spot on. But if you are interested in different people's opinions on these specific issues, here's mine:

Code lines should be as long as makes the code readable and makes sense. Artificially breaking lines at 80 because old character cells terminals had 80 columns is a bit of a bunk. Clarity rules, and so do horizontal scroll bars. I do keep comment blocks narrow so that they can be easily read without scrolling.

Why not? Properly used, the ternary operator can help keep code neat, tidy and readable. Like any other tool, used improperly, it won't.

I cut my teeth on FORTRAN where Structured Programming was king. As a holdover from those days, I tend to write methods with a single return just from habit. However, if multiple returns will make the code cleaner or clearer, I go for it.

But as Fred says, pick something you can all live with and stick to it.
[ February 15, 2008: Message edited by: Bear Bibeault ]
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
P.S. What, no religious wars about tabs vs. spaces? :roll:
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 37496
547
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vandre Caetano:
if a method should have more than 1 return (just a note: someone told me that its wrong to have 2 returns in OOP)

There's more than 2 choices here. You could have a method with 1 return, 2 returns or a whole pile of them. Some people (such as myself) are ok with two returns, but not a while pile. The "whole pile" often is hard to refactor easily even if it is clear. The two is often one at the beginning to deal with an error condition and the main one at the end.
 
Jason Ferguson
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bear Bibeault:
P.S. What, no religious wars about tabs vs. spaces? :roll:


Naw, just use a whitespace-eating filter and the difference between tabs and space doesn't matter anymore.

(p.s.: spaces)
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Bear]: P.S. What, no religious wars about tabs vs. spaces? :roll:

Those are more easly resolved by blackmail or quiet assassination, rather than open warfare.
 
Vandre Caetano
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bear Bibeault:
Artificially breaking lines at 80 because old character cells terminals had 80 columns is a bit of a bunk.

So thats the reason behind the 80 characters!!! I was wandering myself for quite a while now

Originally posted by Bear Bibeault:
[QB]P.S. What, no religious wars about tabs vs. spaces? :roll:


I forgot about those!! I'll bring those up to work as soon as monday
but really, to me, it can go either way (p.s.: spaces too)

By the way, have you ever heard about that more than 1 return thing been agains OOP or anything like it? at all?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My own answers:

80 characters: I favor this limit, still. Sure, most of the time I could support more than that. But sometimes I'm using my 12" laptop and running IntelliJ, which wants to use space on the sides for other frames, which limits the area available for code. And sometimes you're on someone else's terminal and the first editing tool you can find is a 80-character vi window. Or maybe you're in a meeting showing code on an overhead projector, with more limited space than usual (or more need to increase the font size so others can see). Or maybe you're posting your code to JavaRanch, and you don't really know what sort of browser and system all your readers will have. I think that an 80-character limit does a decent job of handling these cases.

Unfortunately many Java class names are pretty long, and since Java is strongly typed you often have to write

and unfortunately this does encourage one to raise the limit to, say, 120 characters. I can live with that. But people who use more than 120 characters should be shot. Repeatedly. (Which is why I put the parameters on the next line, but you get the idea.)

Bear says horizontal scroll bars rule. I disagree, except maybe when using a Mac laptop with easy two-fingered horizontal scrolling. (Now that IntelliJ finally makes proper use of the horizontal scrolling from this device.) In general horizontal scrolling is a pain, and to be avoided whenever possible.

Ternary expressions: heck yes, I love them. Personally I will sometimes put several on one line, but I understand that many people have a problem with that. However anyone who won't let me put a single ternary expression on a line is my enemy, and we must do battle.

More than one return: I am fine with having multiple returns. However I am also fairly religious about keeping my methods short (typically ten lines or less, max twenty) so it's easy to spot the returns (or breaks or continues) and still understand the overall structure of that method. If the method becomes really long and the multiple returns are hard to spot, that's a problem. But the solution is usually to factor the method into smaller methods, not to eliminate the multiple returns.

Tabs vs spaces: spaces. Or I can live with tabs if you use just tabs. But mixing tabs and spaces is evil, especially if you use a tab size other than 8. Because I keep my editor set to a tab size of 8 in order to properly see code from the JDK that mixes tabs and spaces (because Sun is evil, apparently) and if anyone uses tabs with a different setting, it won't show up correctly.

Boxers or briefs: boxers.
[ February 15, 2008: Message edited by: Jim Yingst ]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Vandre]: By the way, have you ever heard about that more than 1 return thing been agains OOP or anything like it? at all?

This really has nothing to do with OOP - it came from structured programming, an earlier style which still influences many people. As a result there are many who think multiple returns are bad programming, period. But there's nothing especially OOP about this idea. Plenty of OOP programmers use multiple returns, and plenty do not.
[ February 15, 2008: Message edited by: Jim Yingst ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeanne Boyarsky:

Some people (such as myself) are ok with two returns, but not a while pile.


If a method is big enough to be *able* to contain a whole pile of returns, I would have a bigger issue with it than the number of returns...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One disadvantage of having more than one return - or more generally more than one exit point - is that it's harder to formally reason about it. The problems automated refactoring tools have with this is just one manifestation of the problem.

On the other hand, I find that it is often possible to use early returns to better communicate the intention of the code. Take guard clauses, for example. To me, that is a stronger force, so I will happily use multiple returns in my code.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 37496
547
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
If a method is big enough to be *able* to contain a whole pile of returns, I would have a bigger issue with it than the number of returns...

In many cases, I would too. But it depends on the pile. Consider the two following code snippets (let's pretend they have some clear business meaning here and the messages were actually useful.)





I like the second one better. I think they are both clear and don't really think anything is wrong with the first one though. Hence it being a personal coding preference.
 
Marilyn de Queiroz
Sheriff
Posts: 9082
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


but in my experience, it seems that code like this is pretty rare, and that most code is clearer/simpler with one return point.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeanne Boyarsky:

In many cases, I would too. But it depends on the pile. Consider the two following code snippets (let's pretend they have some clear business meaning here and the messages were actually useful.)





I like the second one better. I think they are both clear and don't really think anything is wrong with the first one though. Hence it being a personal coding preference.


I like the first one better - only that I would omit the else keyword. In general, I dislike giving a variable a value and then replacing the value later when there is a good alternative that doesn't need this trick.

Anyway, for this code, I'd probably prefer a totally different implementation:



That's easier to read to me - I spot immediately that there are likely one or two bugs in the implementation...
[ February 17, 2008: Message edited by: Ilja Preuss ]
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 37496
547
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja,
I definitely like your implementation with the method better. I'll have to remember that!
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, HashMaps or arrays can be great for that sort of thing. On the other hand Marilyn's example shows the flexibility you can have with if statements - tests like (!f.isCompleted()) or (g < h) can't really be put in a Map or array. Also the if statements give you more flexibility in the response - you can throw an exception, for example, which you can't really do with the Map. Still, whenever you can use it, a Map can make a great alternative to an if/else if chain, or to a switch statement.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
Yeah, HashMaps or arrays can be great for that sort of thing. On the other hand Marilyn's example shows the flexibility you can have with if statements - tests like (!f.isCompleted()) or (g < h) can't really be put in a Map or array. Also the if statements give you more flexibility in the response - you can throw an exception, for example, which you can't really do with the Map. Still, whenever you can use it, a Map can make a great alternative to an if/else if chain, or to a switch statement.


Yes.

You can still apply a similar strategy if you need more flexibility, though:

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!