Welcome to the Lounge

Paulo Zemek10-Dec-14 19:32

10-Dec-14 19:32

I understand... and I can't say I disagree... that arrives to the point of preference, not to the point of usefulness.
But one thing I never do is 2 (or more) real calls in the same line:
SomeObject.DoCallOne().DoCall2(otherObject.AnotherCallWithAResult(), evenAnotherObject.WithEvenAnExtraCall(), theFinal.ObjectWithTheFinalCall());

modified 11-Dec-14 13:27pm.

Brady Kelly10-Dec-14 21:38

Brady Kelly

10-Dec-14 21:38

Just your contrived example hurts my eyes. I'd hate to see that in real life. Unsure | :~

No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde

RJ Hatch11-Dec-14 6:05

RJ Hatch

11-Dec-14 6:05

Here's a Visual Studio trick:

To debug the if, make sure the text cursor is somewhere in the if condition and press F9.

To debug the method call after the if succeeded, make sure the text cursor is somewhere in the method call and press F9.

Happy Debugging Smile | :)

Paulo Zemek11-Dec-14 7:29

11-Dec-14 7:29

Imagine the if and the call are in the same line. Yet, the condition is false 99% of the time.
Also, the method being called is called from many other places.
If things are in two lines, simply put the breakpoint inside the if, not on the if line. If it is in the same line, you can't do that. Putting the breakpoint inside the method call will not help either, as it is called from many other places, so the best you can do is to create a conditional breakpoint.
I prefer to have things in two lines and put the breakpoint exactly where it is needed.

Daniel Vaughan11-Dec-14 0:24

Daniel Vaughan

11-Dec-14 0:24

It's slower to read an if statement with code on the same line because your eyes have to track to the right. It's the same reason why you shouldn't place form titles and fields on the same line. Here's some articles on it:

http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php[^]

http://uxmag.com/articles/eye-tracking-and-web-usability-a-good-fit[^]

Daniel Vaughan
Twitter | Blog | Microsoft MVP | Projects: Calcium SDK, Clog | LinkedIn

Brady Kelly11-Dec-14 0:47

Brady Kelly

11-Dec-14 0:47

Cool, thanks. I've bookmarked those.

No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde

StatementTerminator11-Dec-14 8:18

11-Dec-14 8:18

Brady Kelly wrote:
I prefer
if (something) DoAB();
for the latter. I never use it, but have recently come across it. It seems more readable to me.

Me too, if you must omit the braces then it's best to put it on one line. That way you don't have to worry about someone coming along later, not paying attention, and doing this:

if (something)
  DoA();
  DoB();

Oleg A.Lukin10-Dec-14 23:06

Oleg A.Lukin

10-Dec-14 23:06

That works fine until you get this in the code after all Smile | :)

C++

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

When I first saw that bug I got even more convinced see that my approach to braces everywhere as a must works better in the end.

Banking establishments are more dangerous than standing armies. T.Jefferson

Paulo Zemek11-Dec-14 6:45

11-Dec-14 6:45

I, for example, would never write the code like that. I can write an if without the {}, but I always put an extra line break after the call. And seeing two lines after the if simply looks wrong.

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
  goto fail;

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
  goto fail;
  goto fail; // why the hell there's a line of code here? It is not important what it does, it looks wrong.

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
  goto fail;

So, this kind of error is as ugly to me as this (in fact, even uglier as the excessive {} somewhat hide the problem):

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
  goto fail;
}

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
  goto fail;
}
  goto fail; // Doesn't this look wrong?

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
  goto fail;
}

But developers can also commit these errors (and by simply taking a looks without reading the code, I don't spot anything wrong):

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
  goto fail;
}

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
  goto fail;
} // Oh, it looks like an else is missing...
{
  goto fail;
}

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
  goto fail;
}

// So the code gets corrected to...
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
{
  goto fail;
}

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
  goto fail;
}
else
{
  goto fail;
}

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
  goto fail;
}

modified 11-Dec-14 13:35pm.

Oleg A.Lukin11-Dec-14 21:15

Oleg A.Lukin

11-Dec-14 21:15

Well, I won't write anything such as that either. But since this a real world example of infamous 'goto fail' bug obviously other people do.

In general I'd say that none of your samples with braces would've passed my code review, but I admit your first sample should attract review attention as well, it'll probably will attract enough attention from any reviewer. Still I'd say that with braces style the code like that most probably would not leave the developer and will be fixed before review

Banking establishments are more dangerous than standing armies. T.Jefferson

tom144311-Dec-14 3:32

tom1443

11-Dec-14 3:32

I don't care what way you do it as long as it is not:

if (something) {
DoA()
}

Yuck!

But seriously - if the biggest problem your project has is where people put or don't put the braces you are doing pretty good.

StatementTerminator11-Dec-14 8:30

11-Dec-14 8:30

Paulo Zemek wrote:
I agree with you. And I am actually the kind of person that when has to modify something like:

C#
if (something)
{
  DoA();
  DoB();
}
To only call a DoAB(), I will go there and kill the extra { and }. So, I have more work doing that, but I keep consistency.

So, it becomes:

C#
if (something)
  DoAB();

Are you serious? You re-factor and combine methods just so you can avoid braces and use a dangerous bad practice?

Paulo Zemek11-Dec-14 8:37

11-Dec-14 8:37

No, I don't refactor and combine methods... I was only giving an example. What's more probably is that I extract an entire block (with many calls) into a single method. But for the example I used two calls.

Sander Rossel10-Dec-14 10:21

Sander Rossel

10-Dec-14 10:21

And why couldn't you write

if (condition)
{
    this.DoThis();
}
else
{
    this.DoThat();
}

Now this code is totally unambiguous Smile | :)

Although I know some people who really hate this...

My blog[^]

public class SanderRossel : Lazy<Person>
{
   public void DoWork()
   {
      throw new NotSupportedException();
   }
}

Ian Shlasko10-Dec-14 11:16

Ian Shlasko

10-Dec-14 11:16

That's not good enough...

if 
(
  condition
)
{ 
  this
  .
  DoThis
  (
  )
  ;
}
else
{
  this
  .
  DoThat
  (
  )
  ;
}

It's not properly formatted until there's only one token per line. Smile | :)

Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)

Jeremy Falcon10-Dec-14 11:23

Jeremy Falcon

10-Dec-14 11:23

Oooooooo, look at how easy that is to maintain now!! :drool:

Jeremy Falcon

Sander Rossel10-Dec-14 11:29

Sander Rossel

10-Dec-14 11:29

if (condition) { this.DoThis(); } else { this.DoThat(); }

You probably meant

Ian Shlasko wrote:
It's not properly formatted until there's only one ~~token per~~ line in the entire application.

I guess it's theoretically possible... Unsure | :~

My blog[^]

public class SanderRossel : Lazy<Person>
{
   public void DoWork()
   {
      throw new NotSupportedException();
   }
}

glennPattonWork310-Dec-14 11:50

glennPattonWork3

10-Dec-14 11:50

Way back in my College days the Software Lecturer told us (the class) it wasn't possible to do the above. I proved her wrong by writing a short Pascal (I think) program with no returns all on one line, ah Youth Smile | :)

_Damian S_10-Dec-14 11:55

_Damian S_

10-Dec-14 11:55

The end of the story -

"...and that's how I got to repeat introduction to programming!!"

Quad skating his way through the world since the early 80's...

Booger Mobile - My bright green 1964 Ford Falcon - check out the blog here!! | If you feel generous - make a donation to Camp Quality!!

PIEBALDconsult10-Dec-14 14:01

PIEBALDconsult

10-Dec-14 14:01

Quite. The maturity of a programming language may (in part) be calculated by how many newlines are required. A proper language requires none.

StatementTerminator11-Dec-14 8:38

11-Dec-14 8:38

PIEBALDconsult wrote:
Quite. The maturity of a programming language may (in part) be calculated by how many newlines are required. A proper language requires none.

Just for making that statement, you should be forced to a maintain decade-old Perl CGI system.

PIEBALDconsult11-Dec-14 12:10

PIEBALDconsult

11-Dec-14 12:10

Perl is a scripting language; not a programming language.

StatementTerminator12-Dec-14 3:16

12-Dec-14 3:16

Yeah true, you really need to be pedantic about a joke?