Thursday, April 8, 2010

Indentation, indentation...

So, lately I see many developers prefer what I call ASCII Art Indentation style such as:


Class Foo
def bar(params = {})
Barf.find(params.merge :key => "value",
:key2 => "value2", ... and so on )
end
end


with the claim that it reads better, and you know exactly where to look for things.

I say it's completely opposite. It is no where near intuitive.

  • Say you have to change params to parameter_name_that_makes_more_sense ? you have to adjust your whole code base to reflect your tiny change, and apparently no one does.

  • For something like:

    Sundae.new(Icecream.with_fruit.no_sugar.all(:include => [:nutrition_facts, :production_plan]), :whipped_cream => WhippedCream.no_fat.first(:conditions => ["make is not :make and calorie < :calorie", {:make => "Booga", :calorie => 120}]))

    How do you systematically define the ASCII Art Indentation scheme that every one will follow and give exactly the same indentation? Where do you look for the make of the whipped cream? Not easy.



And for some reason, people loath my style of indentation: 1 more soft tab when you open a paren, brace, or bracket followed by a new line. and new line and one fewer soft tab before the close of the matching paren, brace, or bracket. It is said it's hard to see where things are, and it increases the number of lines. But behold:

Sundae.new(
Icecream.with_fruit.no_sugar.all(
:include => [:nutrition_facts, :production_plan]
),
:whipped_cream => WhippedCream.no_fat.first(
:conditions => [
"make is not :make and calorie < :calorie",
{:make => "Booga", :calorie => 120}
]
)
)


  • You can choose not to indent if your list is small enough, less than, say, 40 characters, half the 80x24 line.

  • You can write your code easily to indent stuff for you, consistently.

  • You can instruct people easily to indent the exact same way and give the exact same result.

  • You know exactly where you miss your close paren.

  • You know exactly where you can find your make of the whipped cream.

  • Your code rarely falls off the right edge while leaving an airstrip on the left side.



Prove me wrong, someone.

.not is EVIL!

What's a .not?

.not is a decorator method that decorates the object, so that the boolean method call that immediately follows the not call is negated. For example, if self.is_italic? returns true, self.not.is_italic? returns false.

Why would people use .not?

The only reason I have heard so far is because it sounds more like English...Pffft, sounds more like English!

Person.find_by_name("Paul Frank").not.is_popular?

How is that anyway similar to English: Is Paul Frank not popular?

What's wrong with logical negation '!' ? The only reason I have heard so far is that it's at the head of the statement, and with long condition, it falls off the screen... Pffft, falls off the screen!

First, I don't believe in reinventing the wheel that is worse than the original one.
Second, instead of using a CPU to flip a bit, we malloc the heap, create an object, extend some other object with this object, which alias the method to use a CPU to flip the flipping bit!
Oh, did I mention it's stupid?

In addition to that, .not is broken. In any given object, you cannot call .not on the boolean variable.

Class Person
@humorous = false;

def foo
@humorous.not #=> is not going to do anything!
end
end

More over, what prevents someone from doing foo = bar.not, and a thousand lines later, some other call foo.is_real? without knowing that it is being 'notted'?

So you cannot get rid of ! anyway. The best you can do is use the not operator to avoid !, then you have precedence problem to think about.

People then say oh who cares, how many CPU time do you use over that? I'd rather have more style than looking like C.

Well, you see, you don't usually run around a building complex just to go from your desk to the break room 25 feet away, even though it doesn't affect one bit the history of mankind. You don't do that because it's stupid. Oh, and did I mention .not is stupid in exactly the same way?

! has been around since the dawn of computer programming. Whoever thinks ! is not readable should quit programming and do some research on herbal hair gel. If your condition is way too long for you to see ! on a 24" 1080p widescreen, it's a code smell that you should rethink your logic, or model design in general. Whoever thinks ! is ugly and remind them of C should appreciate their own breadth of knowledge, and that without C there is no .not, and the fact that languages are means, not the goal.

Remind yourselves to always do the simplest thing that makes sense. .not is not simple, and not making much of a sense either.
\No new line at the end of file.