Win a copy of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 this week in the Programmer Certification 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
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

How far will you go for consistent style?

 
Rancher
Posts: 506
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Say your team likes to write their if statements like this

If(booleanVariable == false)
And
If(booleanVariable == true)



What would you do?

 
author & internet detective
Posts: 39613
782
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would mention that it is redundant and then let it go
 
Sheriff
Posts: 24658
58
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The whole team? Or just one or two of them? I think that might make a difference.

Me, I maintain a ten-year-old code base. It was all written by me, but naturally "me" ten years ago is different from "me" now. So when I notice old code with substandard things like missing brackets around a one-line if-statement, I usually fix it up. But then I don't need to worry about hurt feelings.
 
Al Hobbs
Rancher
Posts: 506
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All of then write like that haha
 
Marshal
Posts: 66237
250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nowadays? Until they write = instead of ==?
 
Bartender
Posts: 9588
13
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I got a negative comment about that kind of code (testing a boolean var) in a college assignment.  The professor said that it showed a fundamental misunderstanding about how the language worked.  So, yea, I'd have a dim view of seeing that construction in professional code.
The worst style argument I've seen is two coworkers arguing over this (advocated by the Sun Java Style Guide):

verses this (advocated by the JavaRanch Style Guide):


They went around for a year or so until the proponent of the latter style left the team and the proponent of the former stormed through the entire code base updating every instance.  
 
Saloon Keeper
Posts: 10783
230
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That would never fly in our team. All code changes are reviewed, and somebody making changes just for the sake of spreading their personal preference would never get their pull requests approved.

When people in our team get into a disagreement on how a certain piece of code should be formatted, we have a 5-10 minute meeting to hear the pros and cons of each, and then we determine what style to use by popular vote. Then we add a rule to our style checker to make sure the style is followed consistently. Old code is updated as we work on it to incorporate new features and bug-fixes.

So really, if most people in the team preferred to use if(condition == true), that's probably how it would stay. It's unlikely though, as that particular coding style is usually already caught by standard style checkers in the IDE. And if most of my team really preferred to code like that, I'd probably request to be in another team or find another job.
 
Marshal
Posts: 7271
492
Mac OS X VI Editor BSD Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Al Hobbs wrote:Say your team likes to write their if statements like this

or

What would you do?


Few years back on one of coderanch forums I saw somebody claiming that writing == true or == false appear to be more readable and sounds clearer spelt out loud. Well, I'd say that depends a lot on the variable name you have in the condition.

Purely from readability point of view, if the variable name were named exactly as in this example:
I'd say it reads indeed better than

Where I'm coming from... if the style mentioned by the OP is a preferred one among the certain team, there is a chance that variable name(s) are poorly chosen (i.e.: jobRunningState), so such ideas perhaps even naturally come up.

I'm not sure what kind of team (relatively experienced) would choose having some better named variable to check against == true/false. For instance:

Personally to me, that doesn't even read fluently and feels that you made a mistake:


Yeah, probably there are areas where opinions may differ, but I'm doubted here it is one of those.
 
Marshal
Posts: 14386
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:And if most of my team really preferred to code like that, I'd probably request to be in another team or find another job.


Second that, with no second thoughts.

On my team, we agreed to always use the IDE to format. If there was a particular section of code we wanted formatted in a specific way that wasn't what the IDE would format it to, then we'd use the IDE's mechanism to skip autoformatting for that section. It was a working agreement that everyone agreed to and usually abided by. If everyone gets into the habit of using CMD+SHIFT+L (IntelliJ IDEA) or CMD-Shift-F (Eclipse) then personal preferences seldom are an issue: it's the team standard so personal preferences need to be set aside.

My selling point was that by using a consistent style, our code would start to look as if it were written by the same person, at least style-wise. That went back to collective ownership of the code, something we valued as a team. If you think that limited individual creativity somehow, well, it didn't. We practiced pair and mob programming and that focused our attention on more important things, like design, and testing, and refactoring. Compared to those challenges, individual style preferences seemed frivolous and trivial and it never was an issue for us.
 
Master Rancher
Posts: 3399
33
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even with good variable names, I do see some cases where I can agree that using == may look more readable.  Specifically, I think the negative case may be more readable.  So for example:

looks perfectly good compared to

However, comparing

to

I'm not as sure here.  I find the ! somewhat less readable, easy to miss (especially given Java's predilection towards heinously long names).  So I'm tempted to favor the == false since you're unlikely to miss that.

That said, I don't think I have never actually used this style, and probably never will; I appreciate that I don't want to accidentally write = true or = false, and also I value consistency with widely-used standards.  But the ! is the part that does give me pause...

 
Junilu Lacar
Marshal
Posts: 14386
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Mike Simmons wrote:But the ! is the part that does give me pause...


Agree. My first stab would be to try isNotSpecialCondition or if there's a natural opposite of the word, just rename to that one, like done <--> ongoing, abnormal <--> normal, special <--> normal, high <--> low, ... along those lines. Sometimes the "isNot" makes the most sense and sometimes I'll even extract to private methods:

My inner Premature Optimizer used to get really twitchy about that kind of thing but after a while and after learning that Java can easily optimize that kind of code in the background, I got over it.
 
Saloon Keeper
Posts: 21266
138
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the things about C that I miss greatly is its pre-processor. Consider the following:


That allowed you to code


Which is a lot safer, since that skinny little "!" can be easily missed on cursory reading.

On the other hand:

is just begging for trouble and the only reason that it isn't begging for major trouble is that if you forget to type/accidently erase that second equals sign, the compiler will whine at you.

The construct

isn't really a good practice to get into. Some systems define "false" as "Anything that isn't true" or sometimes vice versa. I've seen true be 1, 'T', 111111..., -1 and a number of other things, depending on the platform. Which is why doing a true boolean expression (if x) is much safer as a general rule than doing an equality test (if x == true).

Also, having trained formally in mathematical logic, you don't do "if x == true". Mathematics hates coding 3 things when 1 cryptic one will do

On the subject of code formatting, those wars go way back, but generally there are some sort of shop standards. And there are tools that can normalize formatting in bulk. In addition to stuff like the built-in formatter in IDEs like Eclipse, there are also stand-alone formatters like Jalopy. Some shops even run code through a formatter as a plug-in to version control check-in.
 
Tim Holloway
Saloon Keeper
Posts: 21266
138
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Addendum.

If you look at JEE Unified Expression Language, you'll discover that in addition to straight Java syntax, EL also supports the operators "and", "or", "not", "empty", "lt", "gt", 'eq", "ne" and a few others. While part of this is because some of the aforementioned operators are also "magic" characters in XML and thus having text alternatives avoids ambiguity and fiddling with entity escapes, it also makes the whole expression business a lot more civilized.
 
Junilu Lacar
Marshal
Posts: 14386
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't know why these things happen to me with fair regularity. Was reading the 2nd edition of Extreme Programming Explained: Embrace Change by Kent Beck just now and came upon this:

Kent Beck wrote:... people get passionate about coding style. While there are undoubtedly better styles and worse styles, the most important style issue is that the team chooses to work towards a common style. Idiosyncratic coding styles and the values revealed by them, individual freedom at all costs, don’t help the team succeed.


I guess I shouldn't be surprised though. After all, Kent Beck has been one of my great influences in anything to do with programming.
 
Campbell Ritchie
Marshal
Posts: 66237
250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
He is right; if you are working in a team then formatting styles must all be consistent. If the players all wear the same colour shirts during a football match, the programmers have to use the same number of spaces for indenting.
 
Do the next thing next. That’s a pretty good rule. Read the tiny ad, that’s a pretty good rule, too.
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!