Why is so much code like this? - page 3

New comment
 
RaptorUK:

But doesn't that mean that if they are asking for help with syntax or logic the code isn't going to " . . be syntactically and logically correct;" ?

Yes, you are right. But in the context of discussing the more (or less) effective coding styles/practices, the most important aspect is that the code be syntactically and logically correct, regardless of the coding style used. I guess another way of saying it is that style must give way to syntactically and logically correct code--the primary question is not whether the code looks good and is easily readable, but, rather, is it syntactically and logically correct to perform the task for which it is written. :)

I also agree about // comments. One can never have too many // comments, both to refresh the original programmer's mind as to the particulars of the various parts of code and to assist/help others' comprehension of the code post-completion/implementation.

 
Thirteen:

Yes, you are right. But in the context of discussing the more (or less) effective coding styles/practices, the most important aspect is that the code be syntactically and logically correct, regardless of the coding style used. I guess another way of saying it is that style must give way to syntactically and logically correct code--the primary question is not whether the code looks good and is easily readable, but, rather, is it syntactically and logically correct to perform the task for which it is written. :)

Ah OK, I see what you are saying . . . beautifully presented code is of no use if it doesn't work . . . . but perhaps it is easier to fix ?
 
RaptorUK:
Ah OK, I see what you are saying . . . beautifully presented code is of no use if it doesn't work . . . . but perhaps it is easier to fix ?
Correct. In other words, coding styles/practices and presentation, which are largely the choice of the programmer, are a means to an end (the end being syntactically and logically correct code). :) When the code can be easily read and comprehended by the programmer (and subsequently by others who didn't write the code), it is much easier to detect and correct syntactical and/or logical errors.
 

I think most coding styles allow for as much readability as the coder wants or needs, I close up my code when it is finished and working, but it is easy to open it back up with a few line spaces if I need to share it or discuss it. I think a coding format should support easy identification of a missing brace, and easy identification of if else pairs when there is a complex if else tree with multiple branches. I never adopted the K&R style so I would like to see how K&R style coders do it.

 
SDC:

I close up my code when it is finished and working, but it is easy to open it back up with a few line spaces if I need to share it or discuss it.

Why close it up at all? I really don't get the point of squashed up code. If you need to open it up to share/discuss what does that imply?

SDC:

I think a coding format should support easy identification of a missing brace, and easy identification of if else pairs when there is a complex if else tree with multiple branches. I never adopted the K&R style so I would like to see how K&R style coders do it.

For K&R style, The bottom brace aligns with the condition matching. I personally use

1. Consistent indenting

2. For single statement clauses either brace and indent OR have them following the condition unbraced ie.

if (flag) {
   i++;
}

OR

if (flag) i++;

3. Use a decent programmers editor that matches braces.

Matching braces are no issue - most of the linux kernel is written in this style, and it is the Java standard. Though I can see attraction of Allman style as, with K&R style, I would often insert an extra blank line after the condition to unclutter the code. Hmm I might be converted :)

 
ydrol:

Why close it up at all? I really don't get the point of squashed up code. If you need to open it up to share/discuss what does that imply?

For K&R style, The bottom brace aligns with the condition matching. I personally use

1. Consistent indenting

2. For single statement clauses either brace and indent OR have them following the condition unbraced ie.

3. Use a decent programmers editor that matches braces.

Matching braces are no issue - most of the linux kernel is written in this style, and it is the Java standard. Though I can see attraction of Allman style as, with K&R style, I would often insert an extra blank line after the condition to unclutter the code. Hmm I might be converted :)

I just close it up so it takes up less screen space. I like to see as much of it at the same time as can fit on the screen. I dont need a brace matcher, I format it so if i place a cursor behind a brace and run it vertically up the lines with the arrow key, when it touches another brace that one is its pair. if i place it behind an else and do the same thing, when it touches an if that is the if else pair.

In this section of code it is easy to see the third else pairs the first if, the second else pairs the second if the first else pairs the third if because the brace(s) behind each else line up vertically behind its corresponding if brace. Likewise it is easy to see which if's do not have an else because each if brace lines up vertically with its corresponding closing brace in the cluster behind the else. I'm not suggesting everyone else should format code this way just because I happen to like it, but to me, is is compact and logical.

      if(downtrend)
      {if(High[i] < LineDownBuffer[i+1])
       {if(DeMarkerHighBuffer[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
        }else
        {if(DeMarkerHighBuffer[i] < LineDownBuffer[i+1])
         {LineDownBuffer[i] = DeMarkerHighBuffer[i];
       }}}else
       {if(High[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
         LineUpBuffer[i] = DeMarkerLowBuffer[i];
         downtrend = false;
         uptrend = true;
      }}}else
 
SDC: I think most coding styles allow for as much readability as the coder wants or needs, I close up my code when it is finished and working, but it is easy to open it back up with a few line spaces if I need to share it or discuss it. I think a coding format should support easy identification of a missing brace, and easy identification of if else pairs when there is a complex if else tree with multiple branches. I never adopted the K&R style so I would like to see how K&R style coders do it.

I cannot answer this for every-coder using k&r. Honestly, the more I look at your format, the more I like it. Had I adopted the Allman style, I could definitely see myself using your modify version. The braces line_up under each other, gets rid of the opening and closing braces taking up a whole line. You can run your cursor down the i upon the if and find missing braces, no-worrying about tab/indent size conventions, compact mode {see most of your codes on screen}. So yea it's pretty cool, it's just at first look, because I'm not used to it, it seemed confusing. And thats the heart of the matter here.

To-me it seems like allot of American coders adopts the [KnR & Allman] where as the Whitesmiths style seems popular with Europeans. Whitesmith is also the Default style for Mt4. Now there's nothing wrong with any of these styles, it's just when I'm helping someone, I have to keep reminding myself to ignore my K&R style and think more Whitesmith. That or use a code formatter.

Why anyone would want to write "complex if else trees" is beyond me. When someone leaves all the White_Space and formatting within a complex if_nest, it looks like they were trying to design a Snake | Spaghetti | ZigZag across the page. The first if starts on line 1 and ends on line 300, about 150 or %50 of those lines are being held by braces. Instead of the "complex if else trees" why-not just create a function. Then let line_1 actually end on line_1 with if( false ){ return; }.

 

Thanks ubzen I'm glad someone likes my format lol. I use if else a lot, probably because when I first started coding someone told me if else makes fast code, so I got in the habit of doing it that way.

 
SDC:

Thanks ubzen I'm glad someone likes my format lol. I use if else a lot, probably because when I first started coding someone told me if else makes fast code, so I got in the habit of doing it that way.

It's nothing personal


It's times like this when it would have been good to have a formal enforced standard that everyone works to . . . . then we would all be doing the same thing and we would all like your code. And before you ask, no, I'll stick with my Whitesmiths style . . . at least I know what to call it now, thanks ubzen

 
You're welcome SDC and RaptorUK. Coding makes a much easier topic to discuss than Winning_EA. :)
1234
New comment
Reason: