• Post Reply Bookmark Topic Watch Topic
  • New Topic

Style Guide  RSS feed

 
Kurt Van Etten
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was browsing through the Java Programming Style Guide, and most of the guidelines were things I either agreed with or could live with, until I came to the Constructs to Avoid. In particular, these items:

3.1.2 - Never use return in the middle of a method
3.1.4 - Never use break other than in a switch statement

are things I happen to use quite a lot. It seems to me that these generally make my programs simpler and easier to understand; to avoid using them I would have to add multiple additional layers of if...then statements or other conditionals. I'm curious about how other people feel about this. Should I be thinking about changing my programming style?
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A style guide is a guide, not a hard-and-fast rule. those guidelines enforce the conventions of structured programming, whereby every program can be written in terms of sequence, repetition (iteration or recursion) and selection. That convention was developed after the work of Jacopini and Böhm in 1966, which was about the same time object-oriented programming was invented (1967). It was thought that structured programming would make software more reliable.

Many people, myself included, like structured programming, but there are many more who don't follow it, and will happily use break or multiple return. I think you will find yourself in accordance with majority opinion.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
These points, like most things in most style guides, are choices made by a specific individual or team. The most important thing about a style guide is that if you're working on a team that has one, you have to learn to abide by it, whether you agree or not. It's important to have a personal sense of style to adhere to in your own work, and it's important for that sense to be informed by the wisdom and experience of yourself and others.

But it's very rare to read a style guide written by someone else and agree with 100% of it. That's OK. But whether you agree or not, when you're working on a team, you should follow it.

P.S. I happen to agree with you. I don't like flags that exist purely as loop exit conditions: I think they clutter up your code. On the other hand, I am sure you can imagine cases where break and return can be abused to create crazy, hard-to-follow code as well.
 
Kurt Van Etten
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ernest Friedman-Hill wrote:... But whether you agree or not, when you're working on a team, you should follow it.


I'm thinking about doing the Cattle Drive thing, but first I have to reassure myself that I can abide by the rules.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a good reason for not putting return statements only at the bottom of a method. Suppose that you have a long and complicated method (which is, in itself, not a good idea, but let's not focus on that for the sake of this example):

If you, at the top of the method, allocate some resource that needs to be freed before the method returns, you can easily forget to do that when there are returns in multiple places in the middle of the method. You could fix that by writing the code like this:

 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:There is a good reason for not putting return statements only at the bottom of a method. . . .
Have you got a "not" too many in that sentence, Jesper?
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Campbell, fixed...
 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:If you, at the top of the method, allocate some resource that needs to be freed before the method returns, you can easily forget to do that when there are returns in multiple places in the middle of the method.

I'd personally prefer to handle this with try ... finally block, so that the resource gets released not only when returning from the middle of the method, but even in case of exception. I'd say this is sort of a standard in Java.

The supporting argument I've heard about this style was that adhering to it makes it easier to later split the method into smaller ones, if it grows too big.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!