Design Pattern, Implementation Pattern and Best Practices

[simoncpu]

---

Yes, I saw this too, quiet weird in my opinion...

Make more sense for me when if (mymoney == 100 pesos) then if (100pesos == mymoney)

Yepp, makes more sense too. "If my money is equal to 100 pesos" sounds more natural than "If 100 pesos is equal to my money." Naturally, people's mileage will vary, but I personally find that doing if (x == constant) leads to fewer bugs because I only need to remember that the left operand is usually the variable that I need to focus on.

Inside my brain, all equality operations are reduced to "does the left operand, which is always changing, have a value that is the same as the right operand now?" A constant doesn't change, so I need to create a special case inside my brain if I put the constant on the left.

I like to keep my mental models generic, simple, and direct to the point. Lesser cognitive load on my brain frees it to concentrate on more important tasks...

[doomsweek]

from your previous post: I replaced the "TRUE" to 0.
when you write:

if ( variable = 0 )

my compiler triggered this as an error, that's why I keep asking you what compiler you are talking here? what specific language?

Wa koy sure ha pero diba sa C kay wala may boolean na data type? Anything other than 0 is true, so sa case sa:

if(i = 0) {
 /* the program won't ever run the instructions
     in this block
 */
}

ang mahitabo kay i butang ang 0 sa i na variable then i-evaluate ang expression i which is 0 or false. Then sa uban na C compilers kay mo issue naman ug warning kung dili == ang naka suwat sa condition. I think naa toy way para murag i explicit = jd para dili mo issue ug warning. Kalimot nasad ko or nag buot2 lang ko.

[bluedes]

Yepp, makes more sense too. "If my money is equal to 100 pesos" sounds more natural than "If 100 pesos is equal to my money." Naturally, people's mileage will vary, but I personally find that doing if (x == constant) leads to fewer bugs because I only need to remember that the left operand is usually the variable that I need to focus on.

Inside my brain, all equality operations are reduced to "does the left operand, which is always changing, have a value that is the same as the right operand now?" A constant doesn't change, so I need to create a special case inside my brain if I put the constant on the left.

I like to keep my mental models generic, simple, and direct to the point. Lesser cognitive load on my brain frees it to concentrate on more important tasks...

makes more sense if you pattern it into your conditioned thinking..

but in mathematical logic speak, they're both the same..

"If 100 pesos is equal to my money.." sounds pretty much the same ra..

you have to uncondition yourself na they're not the same, because the fact of reality is, they are the same..

.
.

to really see how the same they are, detach "my money" from yourself, and 100.. put "my money" in one hand, and the "100 pesos" in the other.. they're both same when ur able to abstract your identity from your money.. your money is not you.. its your money.. so again, if you say, "If this 100 pesos is equal to this money which is mine", its the same as saying, "If this money (which is mine) is equal to this 100 pesos"..

[bluedes]

Wa koy sure ha pero diba sa C kay wala may boolean na data type? Anything other than 0 is true, so sa case sa:

if(i = 0) {
 /* the program won't ever run the instructions
     in this block
 */
}

ang mahitabo kay i butang ang 0 sa i na variable then i-evaluate ang expression i which is 0 or false. Then sa uban na C compilers kay mo issue naman ug warning kung dili == ang naka suwat sa condition. I think naa toy way para murag i explicit = jd para dili mo issue ug warning. Kalimot nasad ko or nag buot2 lang ko.

naa may flags ang compiler tingale bro, to check for explicit == in the if statement.. but older compilers don't have this option..

[MarkCuering]

naa may flags ang compiler tingale bro, to check for explicit == in the if statement.. but older compilers don't have this option..

if talking FLAGs, it doesn't have any... flags are not there to change the language syntax or how it evaluates expressions, it does not change explicit language to implicit type behavior. Flags I have used so far that concerns about the language are up to /vmm /vms /vms which deals about inheritance (multiple and virtual) only.

Perhaps you can use /Zs for syntax checks (but this is not complete even in MS Compiler), in my old C++ compiler, it does not detect this kind of situation, but if you run the "Syntaxs Check" on the IDE or set this option on the compiler, it sees the error.

[insect111]

From "Best practices for programming in C":

• Be clear in your intentions

....

It is sometimes possible to code in a way that anticipates likely mistakes. For example, you
can put constants on the left of equality comparisons. That is, instead of writing:

       while (c == '\t' || c == ' ' || c == '\n')
        c = getc(f);

You can say:

        while ('\t' == c || ' ' == c || '\n' == c)
         c = getc(f);

This way you will get a compiler diagnostic:

    while ('\t' = c || ' ' == c || '\n' == c)
         c = getc(f);

This style lets the compiler find problems; the above statement is invalid because it tries to
assign a value to '\t'.

[kamsky]

One line 'if' or loop statements with or withour curly brace.

It's a good practice to put a curly brace after if or loop statement even if it's just one-liner.

Consider this statement:

if (condition)
   doSomething();

it would work, but it is error-prone because if you try to add new statement inside inside if block:

    if (condition)
      doSomething();
      doSomething2(); // Wrong! this will evaluated outside if statement

Also, without curly brace it's very difficult to read if you nested ifs:

if (condition)
   if (anotherCondition)
      doSomething();
 else
      doSomethingElse();

Now, which 'if' does the 'else' belong to?

[MarkCuering]

Writing a single line statement shouldn't be like that in the first place:

if (condition)
doSomething()

instead you make it this way:

if (condition) doSomething()
else doOtherthing()

even so, if you make it this way


if (condition)
doSomething()

when you hit enter right after the doSomething function, some IDE will place your line on the leftmost position,letting you remind that your code is outside "if" block statement.

I still prefer to use "{ }" no matter how single lines of code is that... most of the debuggers evaluate blocks statement via curly braces plus you are taking the advantage of collapsing and expanding your codes (just in case your IDE is having that kind of features).

[bluedes]

if talking FLAGs, it doesn't have any... flags are not there to change the language syntax or how it evaluates expressions, it does not change explicit language to implicit type behavior. Flags I have used so far that concerns about the language are up to /vmm /vms /vms which deals about inheritance (multiple and virtual) only.

Perhaps you can use /Zs for syntax checks (but this is not complete even in MS Compiler), in my old C++ compiler, it does not detect this kind of situation, but if you run the "Syntaxs Check" on the IDE or set this option on the compiler, it sees the error.

naa nay flags bro.. mao bitaw nay gamit sa flags.. this if case is not changing the language syntax or how it evaluates expressions.. its just checking for double '=' within an if condition, which is a special case appropriate for flags..

have you ever compiled using gcc with all its superfluous flags?

[bluedes]

From "Best practices for programming in C":

• Be clear in your intentions

....

It is sometimes possible to code in a way that anticipates likely mistakes. For example, you
can put constants on the left of equality comparisons. That is, instead of writing:

       while (c == '\t' || c == ' ' || c == '\n')
        c = getc(f);

You can say:

        while ('\t' == c || ' ' == c || '\n' == c)
         c = getc(f);

This way you will get a compiler diagnostic:

    while ('\t' = c || ' ' == c || '\n' == c)
         c = getc(f);

This style lets the compiler find problems; the above statement is invalid because it tries to
assign a value to '\t'.

thanks for more clarified explanation..

One line 'if' or loop statements with or withour curly brace.

It's a good practice to put a curly brace after if or loop statement even if it's just one-liner.

Consider this statement:

if (condition)
   doSomething();

it would work, but it is error-prone because if you try to add new statement inside inside if block:

    if (condition)
      doSomething();
      doSomething2(); // Wrong! this will evaluated outside if statement

Also, without curly brace it's very difficult to read if you nested ifs:

if (condition)
   if (anotherCondition)
      doSomething();
 else
      doSomethingElse();

Now, which 'if' does the 'else' belong to?

i agree with this one too.. for compiled languages.. because it doesn't matter how many curly braces you put in there, after compilation, they will be converted to machine code anyway..

but for scripted languages, i dont really trust code tidy-ing utilities.. or never really tried them either.. maka-suggest mo dha ug kanang mga minifiers?