Hacker News Reader

Hacker News

Comment by MartinCron | Hacker News Reader

Full thread

MartinCron

Code like Yoda, you must not.

View on HN

The if(0==flag) is perfectly valid for avoiding if(flag=0) bugs.

Of course, I'd use if(!flag)

Honestly, this is like arguing tabs vs spaces.

Tabs vs. spaces is basically an implementation detail of the editor. The point is that the code should always look the same.

This is a semantic issue that doesn't even go away in pseudocode.

Any modern should not allow 'if(flag=0)'.

Any non-modern language should flag a warning on that. And this warning should be set to be an error by any reasonable developer.

What about while? while(flag = 0) looks like a similar error, but while(foo = read()) is a common idiom.

I think some compilers give a warning on while(foo = read()) but not on while((foo = read())).

That would be a broken compiler.

No, I'm pretty sure that's intentional specifically to permit that idiom.

It's usually a warning that you have to turn on explicitly, or one that you can at least turn off (thank heavens).

It's not the choice of keyword that (should) trigger the warning. It's the simple fact that an expression that evaluates to boolean contains an '='. This potential error is trivial for any compiler to flag.

Personally I'm more against "=" being the assignment operator, which should be ":=". But I have no problems with the actual syntax so long as it's clearly defined what (x = y) returns. (Does it return y? x? true if assignment was successful? Does it call a operator=() function that blows up the moon?) In languages where the line between statement and expression is nil it would be especially odd to flag this as illegal.

Flash Builder's Actionscript compiler has saved me from that a couple times in memory, though, so I agree it should be a warning if you don't wrap it in extra parens. gcc also will complain.

Personally I'm more against "=" being the assignment operator, which should be ":=".

The problem with := is that you run the risk of the Pascal trap, in that no language which uses := for assignment has ever become more popular than Pascal.

In general, I just don't like hitting shift, and so am opposed to :=.

Let's compromise and make it ;=.

I'd rather if the compiler simply determined whether or not it was used as an assignment or comparison and just go with a single =.

> Any modern should not allow 'if(flag=0)'.

This is how you set default values for optional argument in Ruby and is very common.

I have never seen "if foo = 0" used to set a value for an optional argument in Ruby. It would either be "def bar(foo=0)" or "foo ||= 0". Can you give any example of what you're talking about?

My mistake. I didn't read parent carefully enough. Although it is common to see something like:

  if(@post = Post.find(params[:id]))
    render @post
  else
    render 'Post not found'
  end

I think PHP allow assignment in 'if'

In C++ flag==0 and !flag are not always the same, but depending on the type of flag, and if that type(or any its parents) has either or both of == or ! operators overloaded.

Pray tell which compiler you are using that won't throw a warning on variable assignment in a condition?

If one side of the expression is longer, putting the shorter one first can improve readability. (Some would argue that you should assign the longer expression to a variable first).

I think that

  if(S_OK == QueryInterface(IID_IUnknown, &p)) {

is clearer than

  if(QueryInterface(IID_IUnknown, &p) == S_OK) {

Reply on news.ycombinator.com