Win a flower (🌹) or copy of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java (📚) this week in the Agile and Other Processes forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Bear Bibeault
  • Liutauras Vilda
  • Devaka Cooray
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • salvin francis
  • Frits Walraven
  • Piet Souris

Style. Which would you prefer?

 
pioneer
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jim Yingst:
I'd agree, except it looks like the else clause in your middle example isn't indented properly to be within the for loop. Is that intentional?

And that's why I just can't take seriously a language that makes invisible whitespace syntactically significant. Seriously, though, I see both languages as useful and different. On one hand you have simplicity of simple code, and on the other hand you have Java.
 
David Harkness
pioneer
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
I'd agree with that. I think the JavaRanch style guide is intended for beginners who are just learning the basics of the language, not for experienced programmers.

and

Originally posted by Jim Yingst:
In the case of the JavaRanch style guide (which I do not endorse personally), the rules given are: never use continue, and never use break other than in a switch statement. There, that was easy.

I've heard the "don't use break or continue" from more than one teacher in the past, and my friend who is taking CS now was told that if one of their programs used it, it was an automatic fail of the assignment with no chance to fix it. I can understand recommending against it for beginners, but mandating it so strictly just seems egregious.

This particular teacher had many other dysfunctionalities, so I wasn't surprised to hear this one. My favorite was spending the entire hour lecture typing up his example program instead of doing it the night before and not even finishing it because he couldn't get it to compile! And this wasn't a junior teacher but the head of the CS department.

Anyway, my point is that this proves that "brace style 3" is wrong.
[ February 03, 2005: Message edited by: David Harkness ]
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[DH]: And that's why I just can't take seriously a language that makes invisible whitespace syntactically significant.

(Yes, I saw the smiley, but I'll go ahead and take you seriously for a moment.)

What happened here is that I saw

and I interpreted it as

I thought this was a problem, because I thought a for loop couldn't have an else clause. But since in Python it can have an else clause, there's no problem. The original code communicated exactly what it was intended to communicate: a for loop with an else clause. There's nothing unclear about the whitespace here - it's just that the language construct was unfamiliar to me.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In defense of style 3, it does look nicer than K&R, and it doesn't waste space like Pascal style. (I.e. the so-called C++ style.) I realize most people don't see wasted space as a big deal - but I still see value in fitting code into fewer lines, because it increases the amount of meaningful code I can see at one time without using my scroll bar. Frankly, braces are not something I really need to see in order to understand the code - the indentation already tells me what I need to know. If it's not indented correctly, I'll go and beat the author with a stick, then use an auto-formatter to fix it.

Anyway - I'm still not a big fan of style 3, but I wanted to acknowledge that it does have some merits at least.
[ February 03, 2005: Message edited by: Jim Yingst ]
 
pioneer
Posts: 1923
Scala Postgres Database Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

converting this to a fixed-number of spaces will be wrong.
And therefore reconverting a special amount of spaces to tabs will be wrong too.

Don't save blanks!

btw.: Braces in seperate lines is called 'Allman-Style' - afaik.
[ February 03, 2005: Message edited by: Stefan Wagner ]
 
Stefan Wagner
pioneer
Posts: 1923
Scala Postgres Database Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh Marilyn, that's ugly:
[/qb]<hr></blockquote>
try it this way:

it's beautiful and right.
[ February 03, 2005: Message edited by: Stefan Wagner ]
 
David Harkness
pioneer
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Imagine how difficult it would be to help beginners in this forum if it was for Python. Why? Because they usually don't use code tags. At least with Java, I can select their unformatted code, paste it into my editor, select all, and do "Format : Source Code". Now I can read their source perfectly, and it even formats using my preferred rules.

As I said, style #3 looks really slick for read-only code. But when I code, I bounce around it way too much, moving lines around quickly as you noted. If I had to select partial lines, paste and reindent ... ugh, no thanks. Now, if the editor could understand the brace style and shift the braces around for me as I cut and pasted lines, then yes it might be nice. Of course, I think editors could do a lot more to keep the formatting strict than they do now. Maybe in another few years we'll see that.

Most other people don't need to deal with this, but the reason I use slightly different formatting for method parameters and control statements (spaces surrounding all punctuation like parens, semi-colon, comma) is so these lines stand out as I'm scanning down the code. When you have poor eyesight, you need all the help you can get.

For all normal statements I stick to "spaces around operators" and that's it. Here is where coloring comes in very handy, making method calls and operators stand out.
[ February 03, 2005: Message edited by: David Harkness ]
 
pioneer
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i don't have to do a lot of imagining, David. i've frequented a few Python forums; they tend to have to harp on code formatting rules the way this place harps on username rules. :roll: i was a member of one that actually had small bits of public-domain Python code for reformatting Python programs into the accepted pseudo-HTML style so people could cut-and-paste it into their web browsers and have it come out looking right.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
M Beck:

um. you know, i'm not entirely sure what Python will do if it finds your code switching from spaces to tabs in mid-flight - that issue has simply never occurred for me.

if i had to guess (and i can't - regrettably - just experiment to find out, as i'm sitting in a computer lab that doesn't have Python installed), my guess would be that Python probably would consider one tab and eight spaces to be equivalent for its purposes. but, really, this situation is incredibly rare in practice, if it even happens at all.


I guess my experience is different. My experience that invisibly mixed tabs and spaces are incredibly common in practice - they seem invariably to be present in any operating code more than a couple years old, for example. It's very easy to use the space bar a few times to try to line something up, and end up with a tab's worth of spaces, especially if you're maintaining code where you don't know whether the original author was trying to use spaces or tabs. Perhaps Python hasn't been around long enough for code to go through several years of maintenance by different people.

I'm still curious about exactly how Python treats tab/space equivalences, if someone knows.
 
steward
Posts: 1840
Eclipse IDE Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by David Harkness:
Imagine how difficult it would be to help beginners in this forum if it was for Python. Why? Because they usually don't use code tags. At least with Java, I can select their unformatted code, paste it into my editor, select all, and do "Format : Source Code". Now I can read their source perfectly, and it even formats using my preferred rules.



Another way to do this is Reply With Quote, grab the code out of the text box and then cancel out of the reply. Unless they didn't format it at all, the formatting returns in the text area. This is the way I do it, because cutting-and-pasting from the main page produces code of only one line (no returns!). Single-line comments will then through off code formatters, as the rest of the program will be treated as a comment.
[ February 04, 2005: Message edited by: Joel McNary ]
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Harkness:

I've heard the "don't use break or continue" from more than one teacher in the past, and my friend who is taking CS now was told that if one of their programs used it, it was an automatic fail of the assignment with no chance to fix it. I can understand recommending against it for beginners, but mandating it so strictly just seems egregious.

There actually is a valid reason for using it; it's just that the reason doesn't really apply to garbage collected languages like Java.

In garbage noncollected languages like C++, one wants to be careful to deallocate any memory one allocates. By ensuring that each block has only a single entry point and a single exit point, all the allocation can be done at the beginning of the block and all the deallocation can be done at the end of it, making it easier to ensure that memory is properly managed.

Freeing memory isn't an issue in Java, of course. I suppose it could be a way of ensuring that database resources get cleaned up, but it seems to me like overkill for that purpose.

Jim Yingst:

In defense of style 3, it does look nicer than K&R, and it doesn't waste space like Pascal style.

David Harkness:

As I said, style #3 looks really slick for read-only code.

I'm not advocating that other people use it for writing their code. I just ask that they let me use it; I read code many more times than I modify it, so my philosophy is to make my code read as clearly as possible even if it takes me a moment more to write it.
 
M Beck
pioneer
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
I guess my experience is different. My experience that invisibly mixed tabs and spaces are incredibly common in practice - they seem invariably to be present in any operating code more than a couple years old, for example. It's very easy to use the space bar a few times to try to line something up, and end up with a tab's worth of spaces, especially if you're maintaining code where you don't know whether the original author was trying to use spaces or tabs. Perhaps Python hasn't been around long enough for code to go through several years of maintenance by different people.



perhaps, although some rather sizable Python projects have been around for several years now; Zope comes to mind. i suspect it's more a matter of this issue having to be resolved up front before people can effectively collaborate on a Python project. i've never seen the question start any heated disputes, though, possibly because nobody thinks plain white space is worth fighting over.

I'm still curious about exactly how Python treats tab/space equivalences, if someone knows.



i'm still not 100% certain, but i've played around a little bit with python's "compiler" module and a carefully designed test file, and it appears my guess was right. as far as i can tell the Python parser considers a tab to be eight spaces, and does something equivalent to tab expansion early on in parsing each line. it's clever enough to detect spaces before a tab, such that "space space tab" still comes out to only eight space-equivalents.

also, unexpected indent level shifts that would not make sense syntactically throw immediate, parse-time exceptions. that means any bugs created this way would have to fit in with the syntactic flow of the code; i imagine that alone would quickly trip up a maintainer who wasn't going with the project's whitespace standard, alerting them to the problem.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Python's official policy on tabs and spaces is spelled out here. So if I'm reading it correctly, a single tab at the beginning of the line would be interpreted the same as eight spaces. A space followed by a tab would also be eight spaces. So would seven spaces followed by a tab. Eight spaces followed by a tab would be sixteen spaces. A tab followed by a space would be nine spaces. Right? (For each preceding sentence, I mean if we're counting from the beginning of the line again.)
 
M Beck
pioneer
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
d'oh! it didn't even occur to me to just look this up in the reference manual. i guess i must spend too much of my Python time in the standard library docs or something. now, i've gotta get back to Java!
 
David Harkness
pioneer
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
In garbage noncollected languages like C++, one wants to be careful to deallocate any memory one allocates. By ensuring that each block has only a single entry point and a single exit point, all the allocation can be done at the beginning of the block and all the deallocation can be done at the end of it, making it easier to ensure that memory is properly managed.

You're the first person to even point that out. Thanks! The only reason I had heard from anyone before yours was "break and continue are effectively goto, and we all know that goto is evil." I can definitely see the value of shying away from them in blocks that do memory allocation in C/C++.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
There actually is a valid reason for using it; it's just that the reason doesn't really apply to garbage collected languages like Java.



There is also a reason that applies to Java, but is rather academic: the flow of code containing continues, breaks or early returns is much harder to analyze mathematically.

This becomes a problem not only when you want to mathematically proof a property of your code, but also when you want to apply formal transformations to it, such as automated refactorings.

I still think that *in practice* the improved readability and simplicity is worth it, though, when used wisely.
 
pioneer
Posts: 385
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are plenty style guides that do look good on paper and on their examples, but when you try to apply them, you see what they are incomplete at least. By the way I would vote for m_ or f_ or anything to help separate class fields from local variables.
 
pioneer
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
why the heck would you advocate even a very partial implementation of Hungarian notation?
Let alone the use of underscores in Java identifiers.

Neither is required and both (especially Hungarian notation) will make a mess of your code.

If you can't distinguish between instance, static, and automatic variables you should rethink your knowledge of the design and implementation, not go looking for Hungarian notation...
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Harkness, regarding avoiding "break" and "continue" to simplify memory deallocation:

You're the first person to even point that out. Thanks! The only reason I had heard from anyone before yours was "break and continue are effectively goto, and we all know that goto is evil." I can definitely see the value of shying away from them in blocks that do memory allocation in C/C++.

I think there are a lot of habits people get into because they know "bad things happen if I don't do that", but they don't know exactly why those habits prevent the bad things. Then if they are asked to explain, they end up saying "don't do it because it's evil".

Interestingly, the C++ code I'm currently porting assiduously avoids multiple returns from functions for the same memory deallocation reasons - but ends up using "goto"s to get to the deallocation code at the exit point.
 
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i dont like breaks so my favorite is the second one even it is not as performant as the first!

greetz
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I brought the partial Hungarian habit to Java from PowerBuilder - one letter prefixes for member, argument and local. Took me a while to get over it. When the classes and methods get small enough the need goes away.
 
Too many men are afraid of being fools - Henry Ford. Foolish tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!