Clarity vs Brevity

I know it depends on you style of coding, but when you write a program, what's more important to you: Clarity or brevity. For example, some people find it very rewarding when they get a lot of 'bang' out of a short amount of code, while others prefere to extend this code for easier readability. What's your oppinion/style?

If I can explain the short code so that I can understand it a month later, I'll do that. Otherwise I'll use the longer method.

Long code unless resources are limited. Or write the long code first, and when the app is finished, replace it with the short code, but keep the long version in a comment.

Brevity and obfuscation is basically for fun.

For work, clarity is much more important.

Code:

---

int foo ( int a, int b ) {
  int c;
  if ( a > b ) {
    c = a;
  } else {
    c = b;
  }
  return c;
}

int bar ( int a, int b ) {
  return a > b ? a : b;
}

---

With gcc at least, these produce identical optimised code

If it's obvious to you, then its obvious to the compiler as well.

Take this example

Code:

---

int foo ( int a, int b ) {
  int  t;
  t = a;
  a = b;
  b = t;
  printf( "%d %d\n", a, b );
}


int bar ( int a, int b ) {
  a ^= b;
  b ^= a;
  a ^= b;
  printf( "%d %d\n", a, b );
}

---

My compiler completely eliminates the swap in the former case, and just passes b,a to printf instead. All you've managed to do in the latter is confuse what is actually going on, so the compiler has to take the conservative approach and do what you asked.

>what's more important to you: Clarity or brevity.
I enjoy one-liners as much as anyone else, but for production code you should err on the side of clarity. The goal isn't to astound people with your brilliance by writing code not even you can understand a day after writing it, but to write code that anyone can follow and easily maintain.

Quote:

---

Originally Posted by Prelude

>what's more important to you: Clarity or brevity.
I enjoy one-liners as much as anyone else, but for production code you should err on the side of clarity. The goal isn't to astound people with your brilliance by writing code not even you can understand a day after writing it, but to write code that anyone can follow and easily maintain.

---

Unless you're worried about job security. Then obfuscation guarantees you're the only one that can work on the code. :D It rarely works though

Quote:

---

Brevity and obfuscation is basically for fun.

For work, clarity is much more important.

---

Of course this first example is very extreme. Any programmer with a bit of experience in C or C++ would probably look at you as if you're insance if you tell him to use the first variant over the second because of clarity, in this simple form.

>Unless you're worried about job security.
If you're worried about job security then you probably write bad code anyway, so you've nothing to lose by trying to improve yourself. :)

aww yee!, really cool guys. Thanks for you input. lol, i know there's sometimes that i wish i could take 50 lines of code and compress it into 5, and say "look how great i am everyone!" hehe. But your right, clarity is much more important in most cases. cheers

IMO,

Code:

---

int bar(int a,int b)
{
    return (a>b?a:b); //return which is bigger (a or b) 
}

---

is clearer than

Code:

---

int foo(int a,int b)
{
  int c;

  if(a>b)
    c = a;
  else
    c = b;

  return c;
}

---

is clearer than

Code:

---

int foo ( int a, int b ) {
  int c;
  if ( a > b ) {
    c = a;
  } else {
    c = b;
  }
  return c;
}

---

Quote:

---

Originally Posted by major_small

IMO,

Code:

---

int bar(int a,int b)
{
    return (a>b?a:b); //return which is bigger (a or b) 
}

---

is clearer than

Code:

---

int foo(int a,int b)
{
  int c;

  if(a>b)
    c = a;
  else
    c = b;

  return c;
}

---

is clearer than

Code:

---

int foo ( int a, int b ) {
  int c;
  if ( a > b ) {
    c = a;
  } else {
    c = b;
  }
  return c;
}

---

---

Right, that doesn't prove much except for that brevity and clarity aren't always mutually exclusive. I think what he meant was something like:

Code:

---

if(x>57&&j<3&&q!=12||!strcmpi(q,d)&&(SuperBit>0x0FF?SuperBit<<9:SuperBit^2)-92&&OMGWTFBBQ)

---

I know that, I was just pointing out that in that case, I disagreed...

Quote:

---

Originally Posted by Prelude

>Unless you're worried about job security.
If you're worried about job security then you probably write bad code anyway...

---

Or you are in the computer field.

No matter how great your code is, layoffs happen. Remember a couple years ago? Job security doesn't exist in today's market. ;)

>No matter how great your code is, layoffs happen.
My point being that if you know your stuff you'll likely find yourself gainfully employed regardless of what happens.

>Remember a couple years ago?
Ugh, don't remind me.

>Job security doesn't exist in today's market.
That's because your definition of job security is too narrow. ;)