|
I got an email today from Springer[^] telling me they have some holiday discount.
They have a $30 gift card. I decided to check it out and it seems you can get it from the site as well.
So I wanted to buy the book Agile! - The Good, the Hype and the Ugly[^] and of course I had to register. Upon registering I got another $5 discount.
I pay in euro's and I got a €30 discount. That means any book under €30 is free!
Unfortunately they didn't have anything I really liked, so I went for Agile! which is only €23,79 (yes, I wasted €6,21!  ).
Anyway, they have quite a lot of science books, so I thought the average CP'er might be interested in a $35/€30 discount.
Valid through december 31st.
And I guess Spinger got their free advertising. Thanks and you're welcome.
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Any link to where you can find those gift cards?
Wrong is evil and must be defeated. - Jeff Ello
(√-sh*t) 2
|
|
|
|
|
On the first fold of the Springer Shop page.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
That's odd, I couldn't see that on the tablet. But I can on the computer.
Wrong is evil and must be defeated. - Jeff Ello
(√-sh*t) 2
|
|
|
|
|
Maybe an error in the "mobile" version?
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Why are people so lazy? For example, how hard is it to
if (condition)
{
DoThis();
}
else
{
DoThat();
}
as opposed to:
if (condition)
DoThis();
else
DoThat();
Pedants 
|
|
|
|
|
They think they need to pay for each character entered?
According to my calculations, I should be able to retire about 5 years after I die.
|
|
|
|
|
I know what you're saying; however, there are times I find the second one easier to read.
For example, if I have several of those on a page the extra symbols spread stuff out.
I still do it the first way, but there are times when the second is easier for me to read.
|
|
|
|
|
I agree with you. And I am actually the kind of person that when has to modify something like:
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:
if (something)
DoAB();
|
|
|
|
|
I prefer
if (something) DoAB(); for the latter. I never use it, but have recently come across it. It seems more readable to me.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
|
|
|
|
|
I don't do if() and the code in the same line. It is more a debug stuff. If I want to debug the if itself I put the breakpoint in that line. If I only want to debug the method call, after the if succeeded, I put the breakpoint in the call line.
|
|
|
|
|
This is true. I always use separate lines for everything myself, but all I was saying is I find if (if stuff) [then stuff]; on one line more readable, in established and (hopefully) debugged code. If I have to debug it myself, I just hit enter and add a breakpoint on the new line. Then use the "source control undo" in solution explorer to revert back to the prior pristine state.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
|
|
|
|
|
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.
|
|
|
|
|
Just your contrived example hurts my eyes. I'd hate to see that in real life. 
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
|
|
|
|
|
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 
|
|
|
|
|
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.
|
|
|
|
|
|
Cool, thanks. I've bookmarked those.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
|
|
|
|
|
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();
|
|
|
|
|
That works fine until you get this in the code after all 
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
|
|
|
|
|
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;
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;
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;
}
{
goto fail;
}
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
{
goto fail;
}
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
Paulo Zemek wrote:
I agree with you. And I am actually the kind of person that when has to modify something like:
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:
if (something)
DoAB(); |
Are you serious? You re-factor and combine methods just so you can avoid braces and use a dangerous bad practice?
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
