Not quite! I think code can be written to make it self explanatory. With appropriate variable, function names along with proper abstraction and refactoring code can be read almost like a prose which eliminates need for comments. At times comments are too annoying because they state the obvious or they are not updated along with the code.

eg: code like this in ruby can explain itself very well!

display_error if not valid_input

Now I do understand that comments cannot be replaced entirely and sometimes it is necessary to add notes to understand the code thus I prefer using comments sparingly and avoid long headers on top of each file. Those headers with author name, dates and other information is unnecessary if right tools are used to maintain your project.

You mean:

  display_error unless valid_input

right?

Right. Unless he means:

    display_error if invalid_input

Why use more different language constructs in a post than necessary?

I don't like "unless". Why do you? Every time I have to actually think about what's happening, I change it to "if" so all the logic is actually written visibly.

I use "unless" in ordinary speech. Unless I'm talking with someone who dislikes the word.

I don't parse/think-about boolean logic like English.

Then you probably won't be happy with languages like Perl and Ruby, DSLs, or the "There is more than one way to do it" line of thinking some people have.

It's a big world out here, there's room for Spock and for Kirk.

I love ruby, and use ruby at my job. I just don't write unless. Certainly there is no cause for someone to say a statement is mistaken just because it used if+not. Nor to guess that someone won't like ruby just because he doesn't like unless.

Saying someone is mistaken because they used "if not" instead of "unless" doesn't align with my understanding either, as I tried to point out by listing yet another way to write the same thing.

OTOH, you made a much more interesting statement than simply saying you didn't like "unless," you took things into a discussion about programming languages resembling vs. not resembling English.

Ruby has a bunch of lispy things that have nothing to do with English, but it also has a bunch of Perl-inspired things that have a lot to do with expressing logical ideas in English-y "prose."

If you can reconcile those two things, then yeah, you'll like all of Ruby. If not, you'll probably find a subset that pleases you. So sure, I can see that you might like the Ruby you use.

You said you use "unless" in English as if that proved it was good to use it in boolean logic too. It doesn't. For example, I am happy to use !, &&, and || in my code, even though they aren't English. The criterion for what makes good code is different than what is good English.

My point was that I think an explicit not is clearer than unless in cases sufficiently complex as to require stopping to think about it. If you're trying to keep track of multiple negations, then having one be in a different form than all the rest does not help. (And meanwhile, there is nothing wrong with a habit of always using if).

"The criterion for what makes good code is different than what is good English."

In total, yes, but that does not mean that there are no things that work in English that also happen to work in code.

Furthermore, it is difficult to generalize about this: some programming languages are entirely unlike English and work very well, others attempt to be like English and are terrible, while others attempt to be like English in some ways and work.

And further to that, some parts of some programs attempt to be like English and work well, while other parts of programs work well when nothing like English.

Now while I understand bang, andand, and oror, they are a terrible legacy of our C++ days. Bang is especially unforgiveable. If we must have a prefix operator, what is wrong with ~, the actual standard symbol for negation?

;-)

p.s. This thread may seem to be a digression, but it seems quite pertinent to an article that talks about writing code for readability.

What's the matter raganwald, jonesing for a blog post now that you've hung up your blogging shoes? :-)

Sadly, cutting out my blogorrhoea has no statistically significant effect on my logorrhoea.

I agree with you that !, &&, || aren't the best idea ever. I wonder if the reason behind them over words is so you don't have to put spaces around them. Omitting spaces seems to be popular with the infix crowd (e.g., they happily give up *,+,- from identifiers just to leave out some spaces).

"I wonder if the reason behind them over words is so you don't have to put spaces around them."

Hunh, that hadn't occurred to me! That's a really interesting conjecture, touching on design trade-offs in neat ways. Thanks!

Code without comments is better than code with outdated comments - this happens quite frequently.

Amen. Comments lie. This happens all the time. Programmers who try to maintain code by reference to the comments will get it wrong. You have to debug the code. Comments, at most, should be a guide to what happens where.

You can write a provable theorem as a stream of symbols from mathematical logic, instead of prose. But, do you really want to read the result? Code can be made clearer through abstraction, certainly, but comments are a domain specific language for helping humans understand computer programs.

It depends on how well you write your code.

Also I think in general hackers should learn to read code. To reverse engineer. To understand what is going on without comments. Then when you do have some comments, it's a bonus (Or just even more confusing and contradictory).

"This is true because code is designed partly for computers while comments can be written entirely for humans."

There are differing degrees to which this is true. Different languages had different design motivations. Smalltalk was specifically designed to be readable by humans. By grade school aged humans, actually! In the Smalltalk community, most regard comments as a "Code Smell."