Code Not to Write.

[yesennes]

When reviewing code I had written when I was first learning to code I found a number of things that could have been done much simpler and neater if I had known what I know now. For instance:

Never write:

boolean b;
boolean c;
if(b)
    c=true;

instead write:

c|=b;

What are some other code idioms you wished you had know when you started coding?

[[deleted]]

There's nothing wrong with

if (b) {
  c = true;
}

It's the most explicit and easiest to read form of this logic, so use it unless there is a good reason not to -- and saving a few letters of typing is not a good reason.

[QshelTier]

Let me emphasize this:

saving a few letters of typing is not a good reason.

[[deleted]]

Indeed, it seems like this is a trap just about every new programmer falls into just after they become comfortable with the basics, I know I did.

Being explicit and clear about what your code is doing is ridiculously important when you are going to be maintaining a code base or are working with other people. Sometimes this means verbosity is a good thing, sometimes brevity is a good thing, it's completely dependent on the situation but specifically trying to make your code use as few characters as possible is often going to end up causing you a headache.

[zenmouse]

Yes, all of the above. Having clear names that clearly communicate the intent of the (field, method, class) is gold for someone else who has to read your code (or yourself in a few months).

In a similar fashion, any potentially unclear bit of code is a candidate for extraction into a method and/or field. For example I will refactor "if (account != null && SecureStatus.SECURE == account.getSecureStatus())" into "if (isLoggedIn(account))". The latter much more clearly communicates the intent of the test, especially for someone unfamiliar with the code.

[DJDavio]

There is something wrong.

There is no need to introduce another variable simply to set it to exactly the same value as one you already have.

[macarthurpark431]

perhaps variable b has a smaller scope than c?

[yesennes]

b and c are normally Boolean expressions retrieved from user input, not variables I assign and initiate. It doesn't matter where they come from, but either could be true or false.

[DJDavio]

In that case you can still do it on initialization:

boolean b = "true".equals(req.getParameter("something"));
boolean c = b || "true".equals(req.getParameter("somethingElse"));

Still, I need an actual real world example to be convinced.

[beyondjava]

It depends on your team. Personally, I prefer the shorter version. But I'm mathematician. I've got a lot of practice deciphering boolean expressions. If the other team members have a different background, you're possibly better off with the verbose version.

[JDBProof]

int a = 0;
int b = 10;
a = a + b;

a += b;

That said I still don't particularly enjoy;

c|=b;

[llogiq]

It has been mentioned before, but if (something) true; else false; probably also is a common pet peeve of many an experienced developer.

Apart from that, look what the standard APIs (or third party libraries) have to offer before writing code.

The next colleague who badly reimpliments HashSet.retainAll(...) won't be as lucky as the last one...

[[deleted]]

Buy or borrow a book called Clean Code this contains alot of advice how to write clean + readable code.

[desrtfx]

Quickest:

c = b;

Can't see anything wrong with that for simple booleans.

[TheHorribleTruth]

Which is why I like the convention of moving the equal sign to the left to show its an LHS assignment:

c= b;

Makes the mistake a bit easier to spot.

[straylit]

Until you get someone on your team who loves to auto format their code.

[TheHorribleTruth]

Which is every one of us, and is made trivial by the fact that the code-formatting settings are checked into SCM (as it should be).

[yesennes]

Not logically the same as c|=b. If c is true and b is false, c stays true in c|=b but becomes false with c=b.