Why would you write that as two lines instead of a block? It not only violates DRY, but if the compiler doesn’t optimize it, it would be testing the conditional twice. Depending on the conditional, that would likely be more expensive than the if-block and double up on any side-effects and/or assignments in the conditional.

Edit: woops old article.

Reading pre-conditions first is nice and all, but I do not like having return statements scattered around functions. They should mainly be at the end IMO.

Hmm good point. I agree with you.

i prefer jerods –
if( someCondition ) MarkAsRead( id );
if( someCondition ) RemoveFromInbox( id );

I see your points here, but there are a few thing I would disagree with or prefer a better solution.

If a section of code is going to be used more than one, certainly make it a method, but just because it isn’t doesn’t mean you shouldn’t.
I would consider “Will this code be self-documenting by being extracted into a method with a good name?”

Also I know the problem you are talking about with having to pass parameters to a method when you extract a method during a refactor.
In my opinion, the proper approach is to go ahead and refactor and then eliminate the parameters by making them members of the object.
If it doesn’t make sense to make them members of the object, you have a class that has more than one responsibility, so break it up.
But, in most cases you can refactor a method out of another method in the class, and find that the 3 parameters it takes can not be refactored into member level variables, which makes everything cleaner and increases the cohesiveness of your class.

I came to this conclusion.

If the code exhibits high readability, why the concern?

I would encapsulate this, as a reusable pattern, after all it is the hokey cokey, and I will use it lots:

PutYourRightFootIn();
TakeYourRightFootOut();
DoTheHokeyPokey();
SpinYourselfAbout();

But I agree with Heiko I would not encapsulate this:

if(someCondition)
{
Post post=posts.First(p => p.Id == id);
post.MarkAsRead();
post.ShowInInbox = false;
}

It reads great, and makes perfect sense, with the assumption that someCondtion has a name with contextual meaning.
More importantly, it is instantly accessible, I dont have to follow a chain of method calls to get to the simple code.

If it is not broken dont fix it, how far can we abstract away our abstractions, the code has to go somewhere.

Will this section of code be used more than once?
Is the code low level, hard to understand?
Is my method already 270 lines of code?

if so break it up / encapsulate it?

Sometimes, and usually, if I find I am writing a curley braced code block, it is usually acting on the values of variables set in the current methods scope.

if(youCantReadCode)
{
wontUnderstandThis = previouslyStatedUnderstanding.Value;
getConfusedByTheBraces = sameAsValuePassedToThisMethod;
confusionLevel = someObjectInThisScope.Value;

}

if we encapsualte that, we have to pass params as well.

if(youCantReadCode)CodeReview(previouslyStatedUnderstanding.Value, sameAsValuePassedToThisMethod, someObjectInThisScope.Value);

That to me looks more confusing than seeing the code in the if block, so

If the number of lines of code to be encapsulated is equal to or less than the number of params required to pass into the encapsualted methods to perform processing, then why bother, its just an extra barrier in getting to the code.

BUt, hey, I dont in fact know.

I just found this interesting and thought I would share.

🙂

http://www.antiifcampaign.com/

Keeping the aforementioned goodness of {} and keeping the code clutter free, consider guard clauses like so:

if(theSkyIsBlue)
{
PutYourRightFootIn();
TakeYourRightFootOut();
DoTheHokeyPokey();
SpinYourselfAbout();
}

becomes

if(!theSkyIsBlue)
return;

PutYourRightFootIn();
TakeYourRightFootOut();
DoTheHokeyPokey();
SpinYourselfAbout();

I think that reading pre-conditions like that in the beginning improves the readability.

Furthermore, although we use { on a new line at work (C# shop), as a JavaScript hobbyist, I’ve switched to { on the same line which saves me one line and reads better IMHO.