Syntax habbits. - Page 2

[<M/>]

If you don't want anyone to steal and understand you code you would do that.

[Reverend Jim]

You do that by compiling the code. If you don't want anyone to see your code then don't release it. If you release horribly obfuscated code then you tell the world that you don't know #### about programming (whether or not that is actually the case). Would you leave a ton of crap in your car as an anti-theft device? It might work, but what image do you project to the world?

[<M/>]

Guess that is a better answer than what i have given :)

[Ketsuekiame]

You do that by compiling the code. If you don't want anyone to see your code then don't release it. If you release horribly obfuscated code then you tell the world that you don't know #### about programming (whether or not that is actually the case). Would you leave a ton of crap in your car as an anti-theft device? It might work, but what image do you project to the world?

Obfuscation is quite a common practice, especially in .net where disassembly of libraries is incredibly easy. If you want to protect something proprietry from potential espionage, it will be obfuscated either manually or using some kind of tool before compiling.

[deceptikon]

Obfuscation is quite a common practice, especially in .net where disassembly of libraries is incredibly easy.

Obfuscation only deters a casual reader. Anyone who's seriously interested in the code will have only a little more difficulty figuring it out from an obfuscated disassembly. Further, no professional in their right mind would manually obfuscate code rather than take advantage of a tool.

[Ketsuekiame]

Obfuscation only deters a casual reader. Anyone who's seriously interested in the code will have only a little more difficulty figuring it out from an obfuscated disassembly. Further, no professional in their right mind would manually obfuscate code rather than take advantage of a tool.

True dat. Just stating that it is actually done on purpose ;)

[riahc3]

public void main ()
{

}

Its clean, its a effective. I have NEVER understood why the hell people put { on the same line as the function. Its not clear.

[Reverend Jim]

What looks more pleasing?

if (some condition) {
    true part
} else {
    false part
}

or

if (some condition)
{
    true part
}
else
{
    false part
}

I prefer the first form. I like a balance between white space and code crunching. If half the lines consist solely of opening or closing brackets then that means that much less information that can be presented at one time on a screen or a page. As my dad used to say, "there's a difference between scratching your a$$ and ripping it to shreds" so either extreme - too much or too little white space - makes the code harder to follow.

[deceptikon]

What looks more pleasing?

I'd add a third option since it's my preference:

if (some condition) {
    true part
}
else {
    false part
}

I prefer the first form. I like a balance between white space and code crunching.

The problem is that your cases are trivial. Consider a long line on the condition that one wants to break into two lines:

if (some long condition &&
    some long conditoon &&
    some long condition) {
    true part
}
else {
    false part
}

This introduces an immediate problem: how do you make a clear separation between the indented condition parts and the if statement's body? You could use a blank line, but I find that less pleasing, so this is a case where I switch to Allman style:

if (some long condition &&
    some long conditoon &&
    some long condition)
{
    true part
}
else {
    false part
}

However, that also introduces an inconsistency with the else clause that uses K&R bracing. So do you just accept it, try to avoid such cases, or use Allman for both clauses?

if (some long condition &&
    some long conditoon &&
    some long condition)
{
    true part
}
else
{
    false part
}

And if you opt for the latter, do you try to resolve the inconsistency with the rest of the code? It's easy to make a case for the simple examples, but when the code becomes more realistic there can be annoying exceptions that need to be resolved if one cares about code aesthetics (as I do). ;)

[Reverend Jim]

That's the thing about a preference as opposed to a hard and fast rule. If you have a style and you refuse to break it, even when it makes complete sense to do so, then you are an idiot. Your examples clearly warrant making an exception. There is consistency and then there is foolish consistency. Fortunately, very few of my if conditions span multiple lines.

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. - Ralph Waldo Emerson

[deceptikon]

Your examples clearly warrant making an exception.

Be careful what you say, the bracing nazis will come knocking on your door. ;)

Fortunately, very few of my if conditions span multiple lines.

Indeed, I try to avoid it as well, for more reasons than listed above. There are a number of code flow issues that make reading broken lines more difficult, even taking into account that long lines in general have readability problems. That's why I'm somewhat annoyed with modern C++ and C# because both encourage long lines through their standard library.