Topic: Reading Code

[Kerry]

Which of these is easier for [you] to read.
I don't mean to ask if you can understand either set of code, I mean which formatting lets can you grasp the code intent easier.

Code: [Select]

(defun fun_1 (l n / a b c d)
    (while (Setq d l)
        (while (< (setq b (length a)) n)
            (setq a (cons (nth b d) a) l (cdr l)))
            (setq  c (cons (reverse a) c)  a nil))
            (reverse c))


Code: [Select]

(defun fun_2 (l n / a b c d)
  (while (setq d l)
    (while (< (setq b (length a)) n)
      (setq a (cons (nth b d) a)
            l (cdr l)
      )
    )
    (setq c (cons (reverse a) c)
          a nil
    )
  )
  (reverse c)
)


[Lee Mac]

Is this another dig at my coding style... 

fun_1  But with the indentation set to how it should be.

[Kerry]

No Lee, this is NOT a dig at you.
I've seen several people attempt to use the closing at end of line format style, and wanted to know what our users think.
The first code block is reproduced exactly as it was posted.
The second as formatted by VLIDE.

[Lee Mac]

No Lee, this is NOT a dig at you.

Just messing with you Kerry 

I realise that was how it was posted - but it isn't the correct way that the end-of-line style is formatted by the VLIDE and makes it difficult to decipher even when you are used to the end-of-line style... bit of unfair survey IMO..

[GDF]

I think the same way about dcl code formatting...

for example:

//To load master widgets used by Arch Program© for AutoCAD®
@include "..\\ARCH.dcl"
dcl_settings :default_dcl_settings {audit_level=0;}

////////////////////////////////////////////////////////////////////////////////////

arch_program_multi_layerreactor_toggle
  :row {children_fixed_height=true; children_fixed_width=true;     
    :arch_multi {}
    :arch_curlaysetreactor {arch_curlaysetreactor;}
    :text_part {label="Leader";}
    :toggle {label = "Poly"; key="poly";}
    :toggle {label = "Bloc"; key="bloc";}     
  }   

////////////////////////////////////////////////////////////////////////////////////

ARCH_ANNO :dialog {key = "set-title"; initial_focus="set-title"; width=93.3; height=21.875;
  :row {
    :boxed_row {label="Control Settings"; width=33.875;
      :column {height=4.025; children_alignment=top;
        :row {
          :toggle {label = "Dtx"; key="dtext"; width=3;}               
          :edit_box {key="txdsv"; edit_width=4;}                 
        }
        :row {       
          :toggle {label = "Mtx"; key="mtext"; width=3;}       
          :edit_box {key="txmsv"; edit_width=4;}
        }       
      }         
      :column {
        :row {         
          :toggle {label = "CSI"; key="csi"; width=3;}
          :toggle {label = "GEN"; key="gen"; width=3;}       
        }
        :row {         
          :button {label="Style"; key="txsty"; fixed_width=true;}
          :arch_35x35_image_15 {key="chx";}
        }
      }
    }
    :boxed_column {label="Annotation Commands";
      :arch_cmdname {arch_cmdname;}       
      :popup_list {key="commands-list"; width=51.5; tabs="11"; multiple_select=false;}
      :spacer {}
    }   
  } 
  :arch_program_multi_layerreactor_toggle {arch_program_multi_layerreactor_toggle;} 
  :row {height=11.875;
    :column {                 
      :text_part {key = "clistag"; width=18;}
      :list_box {key = "clist"; width=18; height=9;} 
      :popup_list {key="issue"; width=18; multiple_select=false;}       
    }   
    :row { 
      :column {
        :list_box {key = "nte"; width=56.5; height=12; allow_accept=true;} //71 12       
      }
      :row {
        :column {
          :arch_35x35_image_15 {key="seq";}
          :arch_35x35_image_15 {key="atx";}         
          :arch_35x35_image_15 {key="btx";}
          :arch_35x35_image_15 {key="case";} 
          :arch_35x35_image_15 {key="sbox";}
        }
        :column {
          :arch_35x35_image_15 {key="fat";}
          :arch_35x35_image_15 {key="ddt";}
          :arch_35x35_image_15 {key="mrgtx";}             
          :arch_35x35_image_15 {key="rtx";}
          :arch_35x35_image_15 {key="it";}
        }
        :column {
          :arch_35x35_image_15 {key="nn";}           
          :arch_35x35_image_15 {key="txn";}       
          :arch_35x35_image_15 {key="txtmatch";} 
          :arch_35x35_image_15 {key="txw";}
          :arch_35x35_image_f15 {}
        }           
      }           
    }
  }     
  :arch_program_textstyle {arch_program_textstyle;}
}

/////////////////////////////////////////////////////////////////////////////////////           

  styletable :dialog {label=" Set-Chg Textstyle:"; alignment=centered; initial_focus="cancel";
   :text {key ="T_num";}
   :list_box {key="TextPop"; width=27; is_default=true; allow_accept=true;}
   :row {
     :spacer {}
     :button {label="eXit"; key="cancel"; fixed_width=true; mnemonic="X";}
     :spacer {}
   }   
 }

[gile]

fun_2

[CAB]

I read my own style best. (fun_2)
I find that I need to reformat the ultra condensed (fun_1) and the expanded style to do any serious investigation of the code.

[alanjt]

fun_2

[Lee Mac]

I find that I need to reformat the ultra condensed (fun_1) and the expanded style to do any serious investigation of the code.

That's funny, I have to do the opposite for other people's code 

[alanjt]

(setq i 1 a "blah") <- Just not easy to look at.

[mkweaver]

fun_2

[pkohut]

fun_2

[ElpanovEvgeniy]

fun_2

[wizman]

that looks famiiar Kerry.. , fun_2 is easier to grasp, i agree, i usually do the visual lisp formatting but this time just tried the other way which i think looks also pleasant.

[Kerry]

wiz,
I changed the name to protect the innocent

Pleasant looking is great, but if I (and others) have to copy code to an editor and format it to make the intent understandable (to me) it's not doing what it's supposed to ... communicate the instructions to solve a problem. If I have to reformat code to be sure of the design I won't bother 9 times out of 10 ; and if someone has a problem to be solved they need the code to be as clear and unambiguous as possible.

This of course is my personal opinion and may bear no kinship to reality.

[wizman]

Thanks Kerry, I consider this more as a guidance. 

[Lee Mac]

The VLIDE formats fun_1 with the following end-of-line style:

Code: [Select]

(defun fun_1  (l n / a b c d)
  (while (setq d l)
    (while (< (setq b (length a)) n)
      (setq a (cons (nth b d) a)
            l (cdr l)))
    (setq c (cons (reverse a) c)
          a nil))
  (reverse c))

I think this is clearer for me 

[jbuzbee]

fun_1

[It's Alive!]

fun_2

[MP]

of the options posted fun_2

my real preference tho is subtly different:

Code: [Select]

(defun fun_3 ( l n / a b c d )
    (while (setq d l)
        (while (< (setq b (length a)) n)
            (setq
                a (cons (nth b d) a)
                l (cdr l)
            )
        )
        (setq
            c (cons (reverse a) c)
            a nil
        )
    )
    (reverse c)
)

[JohnK]

I can see you're point about the (re)formating.

My use of the `end-of-line' style developed when i started to get better with Vim and my studies of Scheme came about. I can "move around" better in most cases with the `end-of-line' style in Vim. Most if not all of scheme code is written in the `end-of-line' style.

If i take your two functions as posted; some days it can go either way but i wold say that fun_2 is easier to read more often than fun_1 because i have more experiences with the fun_2 style (posted, and learning).

When im developing apps on my own i use fun_1 style for several reasons. -e.g. i can either "fold up" regions of code quicker or i can ignore those regions like black-boxes.

So what are we getting at? Would we like to see only code posted in fun_2 type of style (It is the recommended style Autodesk recommends)?

[Kerry]

< .. >
So what are we getting at? Would we like to see only code posted in fun_2 type of style (It is the recommended style Autodesk recommends)?

Thanks John.
I've tried the endOfLineClosure formatting as well but found I had trouble breathing when reading ... from not having the the code blocks obvious ... particularly on larger files.
BUT, to each his own

I'm sure NOT trying to establish a forum standard ... just seeing how many people care enough to post about the issue.