Looking for PYTHONs to read syntax find different casing of a variable and to cross reference variables

[Art Kendall]

Those of you who are familiar with my approach to writing know that I highly value human factors like readability, consistency,.
I hope that my soapboxing over the years was influential in prompting automatic indenting and coloring syntax.


It would be handy in debugging and in improving readability to have a PYTHON command that read a syntax file and
 listed each variable with variations in casing.
Reviewyear
reviewyear
REVIEWYEAR

would each have its own output. The writer could then go back over the syntax  and improve its readability by making it consistent.
Better, if the PYTHON were interactive it could ask which variant should be in the text and then fix it.



In 1970 the COMPILE command for e.g., FORTRAN had a switch /CREF .  CREF means to cross reference.
CREF produced a list of all the variables in the code, what lines the variable occurred on and   which side of the = sign it appeared on.

a useful tool would read the syntax find  each string that  SPSS recognizes as an identical variable note what lines the variable occurs on, whether this is the first mention, is on the left or right of the = sign, or if it is on both sides.  This helps find misspellings, using the same name for what should be different variables, a variable that had not been preceded by a NUMERIC, etc.

[David Marso]

When I get some time I plan to write an application which will do that and so much more!
How would you like something which plows into macros and INCLUDE/INSERT files, does the "Who's your daddy" to all variables in the various files and creates a genealogy for all variables and presents them in a treeview?  Also the logical structure of the entire program is treeviewed.
Yeah, I built one 10 years ago in VB but don't have the source anymore
In general I put SPSS commands in ALL CAPS.
All variable names in lower case.
Logical structure is consistently indented 2 characters per block with + in first position for backward compatibility to the stoned age.  Sometimes in more complicated structures I'll alternate +,-
I sometime see people posting abbreviated commands com, rec etc.  
When I see this I suppress the urge to bust out the flame thrower and go crispy critter on their a$$.  
IMNSHO it is completely unprofessional and downright LAZY.
JUST BECAUSE IT IS PERMITTED DOESN'T MAKE IT RIGHT!  
In fact I refuse to work with such people (good thing I am a solo freelancer)!
If I am programming to a particular version I will use CamelCase for MACROS and longer variable names.
I also set my font to a fixed width (Courier).
Yeah, I'm pretty anal about formatting.
eg:
DO IF (blah).
+  LOOP x=1 TO y.
-    LOOP z=x TO 2000000.
+      COMPUTE blah = blahblah.
-    END LOOP.
+  END LOOP.
END IF.
 

Art Kendall wrote

Those of you who are familiar with my approach to
      writing know that I highly value human factors
      like readability, consistency,.
      I hope that my soapboxing over the years was influential in prompting automatic indenting and coloring syntax.
     
   
    It would be handy in debugging and in improving readability to have
    a PYTHON command that read a syntax file and
     listed each variable with variations in casing.
    Reviewyear
    reviewyear
    REVIEWYEAR
   
    would each have its own output. The writer could then go back over
    the syntax  and improve its readability by making it consistent.
    Better, if the PYTHON were interactive it could ask which variant
    should be in the text and then fix it.
   
   
   
    In 1970 the COMPILE command for e.g., FORTRAN had a switch /CREF .  CREF means to cross
            reference.
          CREF produced a list of
            all the variables in the code, what lines
              the variable occurred on and  
        which side of the = sign it appeared on.
   
    a useful tool would read the syntax find  each string that  SPSS
    recognizes as an identical variable note what lines the variable
    occurs on, whether this is the first mention, is on the left or
    right of the = sign, or if it is on both sides.  This helps find
    misspellings, using the same name for what should be different
    variables, a variable that had not been preceded by a NUMERIC, etc.
   
    --
Art Kendall
Social Research Consultants

[Art Kendall]

That is pretty much what I try to do. Tools to help me do it consistently would be fantastic. Love the auto indent.
I loved having teh structure made cleared by have software doing indent when I was writing FORTRAN.
If you look up the archives for this list for posts from me with the word "pretty" you will see what I mean.
Many of these things were available in the mid-70s in a program for FORTRAN code called {drumroll here} PRETTY.

You will also see in those posts that I thought it would be good to have SPSS produce a new version of syntax that had ccl (concise command language) expanded.  IIRC there was something like that for DCL on the VAX.  I think it was user donated.

exe. ==> EXECUTE.
fre ==> FREQUENCIES.
Vars=  ==> Variables =
Before there were colors in the syntax editor I tried to use initial caps on functions Sqrt.

I strongly endorse fixed font because I often do vertical alignment. You might have noticed that my syntax examples are in fixed font.
DO IF  condition EQ 1     This line has an extra space after IF so that the conditions are vertically aligned.
COMPUTE ...
ELSE IF condition EQ 2.
....
ELSE.
PRINT /' OOPS! Should not be here!"/.

I also like an ELSE to trap conditions that were not provided for.

Hint. Hint. Maybe start with a few of those features and build on it.
On 5/12/2013 1:09 PM, David Marso [via SPSSX Discussion] wrote:

When I get some time I plan to write an application which will do that and so much more!
How would you like something which plows into macros and INCLUDE/INSERT files, does the "Who's your daddy" to all variables in the various files and creates a genealogy for all variables and presents them in a treeview?  Also the logical structure of the entire program is treeviewed.
Yeah, I built one 10 years ago in VB but don't have the source anymore
In general I put SPSS commands in ALL CAPS.
All variable names in lower case.
Logical structure is consistently indented 2 characters per block with + in first position for backward compatibility to the stoned age.  Sometimes in more complicated structures I'll alternate +,-
I sometime see people posting abbreviated commands com, rec etc.  
When I see this I suppress the urge to bust out the flame thrower and go crispy critter on their a$$.  
IMNSHO it is completely unprofessional and downright LAZY.
JUST BECAUSE IT IS PERMITTED DOESN'T MAKE IT RIGHT!  
In fact I refuse to work with such people (good thing I am a solo freelancer)!
If I am programming to a particular version I will use CamelCase for MACROS and longer variable names.
I also set my font to a fixed width (Courier).
Yeah, I'm pretty anal about formatting.
eg:
DO IF (blah).
+  LOOP x=1 TO y.
-    LOOP z=x TO 2000000.
+      COMPUTE blah = blahblah.
-    END LOOP.
+  END LOOP.
END IF.
 

Art Kendall wrote

Those of you who are familiar with my approach to
      writing know that I highly value human factors
      like readability, consistency,.
      I hope that my soapboxing over the years was influential in prompting automatic indenting and coloring syntax.
     
   
    It would be handy in debugging and in improving readability to have
    a PYTHON command that read a syntax file and
     listed each variable with variations in casing.
    Reviewyear
    reviewyear
    REVIEWYEAR
   
    would each have its own output. The writer could then go back over
    the syntax  and improve its readability by making it consistent.
    Better, if the PYTHON were interactive it could ask which variant
    should be in the text and then fix it.
   
   
   
    In 1970 the COMPILE command for e.g., FORTRAN had a switch /CREF .  CREF means to cross
            reference.
          CREF produced a list of
            all the variables in the code, what lines
              the variable occurred on and  
        which side of the = sign it appeared on.
   
    a useful tool would read the syntax find  each string that  SPSS
    recognizes as an identical variable note what lines the variable
    occurs on, whether this is the first mention, is on the left or
    right of the = sign, or if it is on both sides.  This helps find
    misspellings, using the same name for what should be different
    variables, a variable that had not been preceded by a NUMERIC, etc.
   
    --
Art Kendall
Social Research Consultants

---

If you reply to this email, your message will be added to the discussion below:

http://spssx-discussion.1045642.n5.nabble.com/Looking-for-PYTHONs-to-read-syntax-find-different-casing-of-a-variable-and-to-cross-reference-variabs-tp5720193p5720195.html

To start a new topic under SPSSX Discussion, email [hidden email]
To unsubscribe from SPSSX Discussion, click here.
NAML

[J. R. Carroll]

Art,

It sounds like you want a "preprocessor" to plow through your code and do the work for you (in part or full). I'd recommend going the route that others have done which is to do basic "linting" which would throw warnings/errors but allow the end-user the ability to pick and choose which they wish to ignore/change. 

Furthermore, for a "linter" to be successful there has to be a standard. As far as I know there is no standard to writing syntax other than it has to be "valid code" (aka has to run). 

It wouldn't be too difficult to write a script that would go through and report all the lint-errors/warnings.  But maybe the listserv should settle on a syntax standard (eg when CamelCase is valid, when to indent, use of execute versus exe, ALLCAPS for commands versus nocaps, etc). 

Of course - being a python developer in my current trade - I'd recommend that it be written in Python.  Not sure what other options there are when you consider the goals.  Depending on the level of sophistication the linter (or preprocessor) might go as low as pythons ASTs.  That would give you the greatest control and allow for an API between SPSS and Python that's on a level of actual syntax conversion (ie you write in pure python and it could convert to pure SPSS syntax and vise versa).  -- but the AST route is a much larger project.  And I'm pretty sure IBM has started this when they started to do the Python integration. 

But I can't imagine DM or anyone putting in the development time on a project like this until a set of coding standards are formalized.  Maybe start a new thread to get a rough draft going?  

So far it sounds like we got:

-all lowercase for variable names

-all caps for commands

-4 space indent for wraps and nests

-EXECUTE > exe

...

-J. R. Carroll

Sent from my iPhone

On May 12, 2013, at 1:44 PM, Art Kendall <[hidden email]> wrote:

That is pretty much what I try to do. Tools to help me do it consistently would be fantastic. Love the auto indent.
I loved having teh structure made cleared by have software doing indent when I was writing FORTRAN.
If you look up the archives for this list for posts from me with the word "pretty" you will see what I mean.
Many of these things were available in the mid-70s in a program for FORTRAN code called {drumroll here} PRETTY.

You will also see in those posts that I thought it would be good to have SPSS produce a new version of syntax that had ccl (concise command language) expanded.  IIRC there was something like that for DCL on the VAX.  I think it was user donated.

exe. ==> EXECUTE.
fre ==> FREQUENCIES.
Vars=  ==> Variables =
Before there were colors in the syntax editor I tried to use initial caps on functions Sqrt.

I strongly endorse fixed font because I often do vertical alignment. You might have noticed that my syntax examples are in fixed font.
DO IF  condition EQ 1     This line has an extra space after IF so that the conditions are vertically aligned.
COMPUTE ...
ELSE IF condition EQ 2.
....
ELSE.
PRINT /' OOPS! Should not be here!"/.

I also like an ELSE to trap conditions that were not provided for.

Hint. Hint. Maybe start with a few of those features and build on it.
On 5/12/2013 1:09 PM, David Marso [via SPSSX Discussion] wrote:

When I get some time I plan to write an application which will do that and so much more!
How would you like something which plows into macros and INCLUDE/INSERT files, does the "Who's your daddy" to all variables in the various files and creates a genealogy for all variables and presents them in a treeview?  Also the logical structure of the entire program is treeviewed.
Yeah, I built one 10 years ago in VB but don't have the source anymore
In general I put SPSS commands in ALL CAPS.
All variable names in lower case.
Logical structure is consistently indented 2 characters per block with + in first position for backward compatibility to the stoned age.  Sometimes in more complicated structures I'll alternate +,-
I sometime see people posting abbreviated commands com, rec etc.  
When I see this I suppress the urge to bust out the flame thrower and go crispy critter on their a$$.  
IMNSHO it is completely unprofessional and downright LAZY.
JUST BECAUSE IT IS PERMITTED DOESN'T MAKE IT RIGHT!  
In fact I refuse to work with such people (good thing I am a solo freelancer)!
If I am programming to a particular version I will use CamelCase for MACROS and longer variable names.
I also set my font to a fixed width (Courier).
Yeah, I'm pretty anal about formatting.
eg:
DO IF (blah).
+  LOOP x=1 TO y.
-    LOOP z=x TO 2000000.
+      COMPUTE blah = blahblah.
-    END LOOP.
+  END LOOP.
END IF.
 

Art Kendall wrote

Those of you who are familiar with my approach to
      writing know that I highly value human factors
      like readability, consistency,.
      I hope that my soapboxing over the years was influential in prompting automatic indenting and coloring syntax.
     
   
    It would be handy in debugging and in improving readability to have
    a PYTHON command that read a syntax file and
     listed each variable with variations in casing.
    Reviewyear
    reviewyear
    REVIEWYEAR
   
    would each have its own output. The writer could then go back over
    the syntax  and improve its readability by making it consistent.
    Better, if the PYTHON were interactive it could ask which variant
    should be in the text and then fix it.
   
   
   
    In 1970 the COMPILE command for e.g., FORTRAN had a switch /CREF .  CREF means to cross
            reference.
          CREF produced a list of
            all the variables in the code, what lines
              the variable occurred on and  
        which side of the = sign it appeared on.
   
    a useful tool would read the syntax find  each string that  SPSS
    recognizes as an identical variable note what lines the variable
    occurs on, whether this is the first mention, is on the left or
    right of the = sign, or if it is on both sides.  This helps find
    misspellings, using the same name for what should be different
    variables, a variable that had not been preceded by a NUMERIC, etc.
   
    --
Art Kendall
Social Research Consultants

---

If you reply to this email, your message will be added to the discussion below:

http://spssx-discussion.1045642.n5.nabble.com/Looking-for-PYTHONs-to-read-syntax-find-different-casing-of-a-variable-and-to-cross-reference-variabs-tp5720193p5720195.html

To start a new topic under SPSSX Discussion, email [hidden email]
To unsubscribe from SPSSX Discussion, click here.
NAML

---

View this message in context: Re: Looking for PYTHONs to read syntax find different casing of a variable and to cross reference variables
Sent from the SPSSX Discussion mailing list archive at Nabble.com.

[David Marso]

"But I can't imagine DM or anyone putting in the development time on a project like this until a set of coding standards are formalized.  Maybe start a new thread to get a rough draft going?  "

Building a prettifier/code standardizer is somewhat low on my list.
If other people want to write unreadable crap that is their business.
If someone posts something on the list like:
com x=blah.
rec  x (......)
do rep (...)
...
end rep.
I am VERY MUCH disinclined to help fix their abomination!!

One thing I am very directed towards building is a code analyzer which presents entire projects into a drill down tree, does the who's your daddy on variables etc.  
Maybe I'll even do it in python rather than C# or VB.Net
so non winblows users can benefit as well.
Let's say it will be donation-ware!
Anybody want to partner up on this?
--

[Albert-Jan Roskam]

>Art,

>
>
>It sounds like you want a "preprocessor" to plow through your code and do the work for you (in part or full). I'd recommend going the route that others have done which is to do basic "linting" which would throw warnings/errors but allow the end-user the ability to pick and choose which they wish to ignore/change.
>
>
>Furthermore, for a "linter" to be successful there has to be a standard. As far as I know there is no standard to writing syntax other than it has to be "valid code" (aka has to run).


===> I was also thinking about lint. Good Python modules for inspiration are pylint, pychecker and pep8. PEP8 is also the style guide for Python: http://www.python.org/dev/peps/pep-0008/. Not everything is relevant for Python, but a lot is.


>It wouldn't be too difficult to write a script that would go through and report all the lint-errors/warnings.  But maybe the listserv should settle on a syntax standard (eg when CamelCase is valid, when to indent, use of execute versus exe, ALLCAPS for commands versus nocaps, etc).


===> I generally think abbrevating commands is a bad idea. New commands cannot be abbreviated, and abbreviated commands are not colour-coded in the SE. As for CamelCase or underscore variable_names: both are readable, so both are ok. It's easy to write a very patronizing coding standard that everybody would hate. Readability is the goal, underscores or casing are ways to achieve that. But once a style has been chose, the coder should be consistent.


>Of course - being a python developer in my current trade - I'd recommend that it be written in Python.  Not sure what other options there are when you consider the goals.  Depending on the level of sophistication the linter (or preprocessor) might go as low as pythons ASTs.  That would give you the greatest control and allow for an API between SPSS and Python that's on a level of actual syntax conversion (ie you write in pure python and it could convert to pure SPSS syntax and vise versa).  -- but the AST route is a much larger project.  And I'm pretty sure IBM has started this when they started to do the Python integration.


You mean something akin to sqlalchemy, but for Spss? Nice idea, but HARD!

>
>But I can't imagine DM or anyone putting in the development time on a project like this until a set of coding standards are formalized.  Maybe start a new thread to get a rough draft going?
>
>
>So far it sounds like we got:
>-all lowercase for variable names
>-all caps for commands   ------>> sorry, it always feels like the coder is SHOUTING at me, I don't like it!
>-4 space indent for wraps and nests
>-EXECUTE > exe

Use a file header (I wrote an extension command for this): title, name, objective, date, syntax file name, etc.
Use file handles with UNC paths (in odbc connect strings: mini-macros).
Specify relevant SET commands (LOCALE, DECIMAL, UNICODE, CCA, etc)
Related to previous: always use SET PRINTBACK=ON.

Use comments and keep them up-to-date
Use inline comments sparingly

Use white space to divide coherent blocks of code

Use meaningful variable names (!!!!!!!!!!!!) <-- the first commandment

Use ALL CAPS for constants
Replace magic numbers with mini macrosUse 79 chars max per line (+ a newline). Readable and printable code!
Indent continued lines (for e.g. VALUE LABELS) so it's batch, not interactive style syntax.

Boolean vars start with 'is'
Embedded SQL in caps
Maybe: use 'eq' for comparisons, and '=' for assignments.
sparse is better than dense (no: compute z=x>y; yes: compute z_coord = x_coord > y_coord)
Use EXECUTE sparingly (only after LAG, MISSING VALUES and a few other cases).
Use $sysmis sparingly.
Use char.* instead of the old string commands In SPSS v21 unicode mode now is the default!)

Divide syntax into meaningful units (-->INSERT). 1500-2000 lines of code is a good maximum amount per syntax.

No more than four nesting levels (e.g. DO IFs)
Code duplication = code smell.
Related to previous: Parametrize your syntax (via @parameters in the Production Facility) rather than making a near-copy for e.g. each year
Have your code reviewed
Do not, not ever, overwrite your source data (put it on read-only, RECODE INTO rather than just RECODE)
....

....

>-J. R. Carroll
>Sent from my iPhone
>
>On May 12, 2013, at 1:44 PM, Art Kendall <[hidden email]> wrote:
>
>
>That is pretty much what I try to do.Tools to help me do it consistentlywould be fantastic. Love the auto indent.
>>I loved having teh structure made cleared by have software doing indent when I was writing FORTRAN.
>>If you look up the archives for this list for posts from me with the word "pretty" you will see what I mean.
>>Many of these things were available in the mid-70s in a program for FORTRAN code called {drumroll here} PRETTY.
>>
>>You will also see in those posts that I thought it would be good to have SPSS produce a new version of syntax that had ccl (concise command language) expanded.  IIRC there was something like that for DCL on the VAX.  I think it was user donated.
>>
>>exe. ==> EXECUTE.
>>fre ==> FREQUENCIES.
>>Vars=  ==> Variables =
>>Before there were colors in the syntax editor I tried to use initial caps on functions Sqrt.
>>
>>I strongly endorse fixed font because I often do vertical alignment. You might have noticed that my syntax examples are in fixed font.
>>DO IF  condition EQ 1     This line has an extra space after IF so that the conditions are vertically aligned.
>>COMPUTE ...
>>ELSE IF condition EQ 2.
>>....
>>ELSE.
>>PRINT /' OOPS! Should not be here!"/.
>>
>>I also like an ELSE to trap conditions that were not provided for.
>>
>>Hint. Hint. Maybe start with a few of those features and build on it.
>>
>>Art Kendall

Social Research Consultants
On 5/12/2013 1:09 PM, David Marso [via SPSSX Discussion] wrote:
>>
>>When I get some time I plan to write an application which will do that and so much more!
>>>How would you like something which plows into macros and
      INCLUDE/INSERT files, does the "Who's your daddy" to all variables
      in the various files and creates a genealogy for all variables and
      presents them in a treeview?  Also the logical structure of the
      entire program is treeviewed.
>>>Yeah, I built one 10 years ago in VB but don't have the source
      anymore
>>>In general I put SPSS commands in ALL CAPS.
>>>All variable names in lower case.
>>>Logical structure is consistently indented 2 characters per block
      with + in first position for backward compatibility to the stoned
      age.  Sometimes in more complicated structures I'll alternate +,-
>>>I sometime see people posting abbreviated commands com, rec etc.
>>>When I see this I suppress the urge to bust out the flame thrower
      and go crispy critter on their a$$.
>>>IMNSHO it is completely unprofessional and downright LAZY.
>>>JUST BECAUSE IT IS PERMITTED DOESN'T MAKE IT RIGHT!
>>>In fact I refuse to work with such people (good thing I am a solo
      freelancer)!
>>>If I am programming to a particular version I will use CamelCase
      for MACROS and longer variable names.

>>>I also set my font to a fixed width (Courier).
>>>Yeah, I'm pretty anal about formatting.
>>>eg:
>>>DO IF (blah).
>>>+  LOOP x=1 TO y.
>>>-    LOOP z=x TO 2000000.
>>>+      COMPUTE blah = blahblah.
>>>-    END LOOP.
>>>+  END LOOP.
>>>END IF.
>>>
>>>
>>>Art Kendall wrote
>>>>Those of you who are familiar with my approach to
>>>>      writing know that I highly value human factors
>>>>      like readability, consistency,.
>>>>      I hope that my soapboxing over the years was

            influential in prompting automatic indenting and coloring
            syntax.
>>>>
>>>>
>>>>    It would be handy in debugging and in improving
            readability to have
>>>>    a PYTHON command that read a syntax file and
>>>>     listed each variable with variations in casing.
>>>>    Reviewyear
>>>>    reviewyear
>>>>    REVIEWYEAR
>>>>
>>>>    would each have its own output. The writer could then go
            back over
>>>>    the syntax  and improve its readability by making it
            consistent.
>>>>    Better, if the PYTHON were interactive it could ask
            which variant
>>>>    should be in the text and then fix it.
>>>>
>>>>
>>>>
>>>>    In 1970 the COMPILE command for e.g., FORTRAN had a
            switch /CREF .  CREF means to cross
>>>>            reference.
>>>>          CREF produced a list of
>>>>            all the variables in the code, what lines
>>>>              the variable occurred on and
>>>>        which side of the = sign it appeared on.
>>>>
>>>>    a useful tool would read the syntax find  each string
            that  SPSS
>>>>    recognizes as an identical variable note what lines the
            variable
>>>>    occurs on, whether this is the first mention, is on the
            left or
>>>>    right of the = sign, or if it is on both sides.  This
            helps find
>>>>    misspellings, using the same name for what should be
            different
>>>>    variables, a variable that had not been preceded by a
            NUMERIC, etc.
>>>>
>>>>    --
>>>>Art Kendall
>>>>Social Research Consultants
>>>Please reply to the list and not to my personal email.
>>>Those desiring my consulting or training services please feel
        free to email me.
>>>---
>>>"Nolite dare sanctum canibus neque mittatis margaritas vestras
        ante porcos ne forte conculcent eas pedibus suis."
>>>Cum es damnatorum possederunt porcos iens ut salire off
        sanguinum cliff in abyssum?"

>>>
>>>>>>________________________________
>>>
>>>If you reply to this email, your message will be added to the discussion below:http://spssx-discussion.1045642.n5.nabble.com/Looking-for-PYTHONs-to-read-syntax-find-different-casing-of-a-variable-and-to-cross-reference-variabs-tp5720193p5720195.html
>>>To start a new topic under SPSSX Discussion, email [hidden email]
>>>To unsubscribe from SPSSX Discussion, click here.
>>>NAML
>>
>>Art Kendall
>>Social Research Consultants
>>>>________________________________
>> View this message in context: Re: Looking for PYTHONs to read syntax  find different casing of a variable and to  cross reference variables
>>Sent from the SPSSX Discussion mailing list archive at Nabble.com.
>>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

[David Marso]

INLINE: Prefixed by /**

Albert-Jan Roskam wrote

>Art,

>
>
>It sounds like you want a "preprocessor" to plow through your code and do the work for you (in part or full). I'd recommend going the route that others have done which is to do basic "linting" which would throw warnings/errors but allow the end-user the ability to pick and choose which they wish to ignore/change.
>
>
>Furthermore, for a "linter" to be successful there has to be a standard. As far as I know there is no standard to writing syntax other than it has to be "valid code" (aka has to run).

/** and there will never be any universilly agreed upon standard.

===> I was also thinking about lint. Good Python modules for inspiration are pylint, pychecker and pep8. PEP8 is also the style guide for Python: http://www.python.org/dev/peps/pep-0008/. Not everything is relevant for Python, but a lot is.


>It wouldn't be too difficult to write a script that would go through and report all the lint-errors/warnings.  But maybe the listserv should settle on a syntax standard (eg when CamelCase is valid, when to indent, use of execute versus exe, ALLCAPS for commands versus nocaps, etc).

"listserv should settle on a syntax standard"

/** That's not likely to happen because everyone has their own style of coding, some more readable than others.  I still write to 11.5 because I only have base v 21 and would like to be able to run my own code in both.  I also write to unspecified versions as many of my clients are academics and the end user might be using something stoned age.  I figure if my code runs perfectly in both 11.5 and 21 then I must be doing something right.  If it fails in in between versions then SPSS/IBM is doing something wrong!
Caveat :  All my variables and macro internals are 8 characters or less in length.  OTOH:  Most of my code is MATRIX which still has LE 8 character restrictions so I don't really miss out on much in that regard.

===> I generally think abbrevating commands is a bad idea. New commands cannot be abbreviated, and abbreviated commands are not colour-coded in the SE. As for CamelCase or underscore variable_names: both are readable, so both are ok. It's easy to write a very patronizing coding standard that everybody would hate. Readability is the goal, underscores or casing are ways to achieve that. But once a style has been chose, the coder should be consistent.


/** I try to be consistent but not always successful often variables end up not being all lower case.
OTOH:  I don't want to be too predictable.

>Of course - being a python developer in my current trade - I'd recommend that it be written in Python.  Not sure what other options there are when you consider the goals.  Depending on the level of sophistication the linter (or preprocessor) might go as low as pythons ASTs.  That would give you the greatest control and allow for an API between SPSS and Python that's on a level of actual syntax conversion (ie you write in pure python and it could convert to pure SPSS syntax and vise versa).  -- but the AST route is a much larger project.  And I'm pretty sure IBM has started this when they started to do the Python integration.


You mean something akin to sqlalchemy, but for Spss? Nice idea, but HARD!

/** Not familiar with AST or sqlalchemy.  Must google.

>
>But I can't imagine DM or anyone putting in the development time on a project like this until a set of coding standards are formalized.  Maybe start a new thread to get a rough draft going?
>
>
>So far it sounds like we got:
>-all lowercase for variable names
>-all caps for commands   ------>> sorry, it always feels like the coder is SHOUTING at me, I don't like it!
>-4 space indent for wraps and nests
>-EXECUTE > exe

/** Reason I opt for uppercase commands is I have the visual contrast to work with.  I find:
COMPUTE x=something.
much easier to map in my brain than
compute x=something.
Especially when in a mass of DO IF... LOOP or do if... loop.
Just the way my brain works.


Use a file header (I wrote an extension command for this): title, name, objective, date, syntax file name, etc.
Use file handles with UNC paths (in odbc connect strings: mini-macros).
Specify relevant SET commands (LOCALE, DECIMAL, UNICODE, CCA, etc)
Related to previous: always use SET PRINTBACK=ON.

/** Yes to all except  SET PRINTBACK=ON.
I use  SET PRINTBACK=OFF to shield users from TMI.
In fact I use OMS to wipe the notes from matrix code unless user specifies some level of debug.

Use comments and keep them up-to-date
Use inline comments sparingly

/** I tend to use a lot of inline comments.  Why is doing otherwise a bad idea?
I have looked at my current project code (~ 2000 lines, only about 1000 are executable ie I comment the hell out of my work)

Use white space to divide coherent blocks of code
/** YES!!!

Use meaningful variable names (!!!!!!!!!!!!) <-- the first commandment
/** and second and third

Use ALL CAPS for constants
/** What is a constant in SPSS?

Replace magic numbers with mini macrosUse 79 chars max per line (+ a newline). Readable and printable code!
Indent continued lines (for e.g. VALUE LABELS) so it's batch, not interactive style syntax.
/** Code should be runnable in both batch and interactive.
Boolean vars start with 'is'
/** ?

Embedded SQL in caps
Maybe: use 'eq' for comparisons, and '=' for assignments.
/** Yeah.  That is one of Art's soapbox things.  I tend to agree and try to be consistent.

sparse is better than dense (no: compute z=x>y; yes: compute z_coord = x_coord > y_coord)
Use EXECUTE sparingly (only after LAG, MISSING VALUES and a few other cases).
Use $sysmis sparingly.
Use char.* instead of the old string commands In SPSS v21 unicode mode now is the default!)

/** If writing for potential stoned age versions CHAR. is not an option.
/** Rather than EXECUTE I would opt for something informative such as FREQ.

Divide syntax into meaningful units (-->INSERT). 1500-2000 lines of code is a good maximum amount per syntax.
 /** Agree for the most part except then you either need to have access to the users disk system.
I would prefer that my code be ignorant of that and don't trust the end user to RTFM to competently define the FILE HANDLES etc.

No more than four nesting levels (e.g. DO IFs)
/** Sometimes impossible if building really complex code.  If it gets too deep I bust into a MACRO call.
Code duplication = code smell.
/** YEP!  DO REPEAT, LOOP, MACRO.

Related to previous: Parametrize your syntax (via @parameters in the Production Facility) rather than making a near-copy for e.g. each year
Have your code reviewed
Do not, not ever, overwrite your source data (put it on read-only, RECODE INTO rather than just RECODE)
....
/** Indeed!
/** SNIP rest .
....

[Kirill Orlov]

(Just one bark from behind the corner)
Art, Jan, David,
Do you really find pleasure in lengthily discussing that crap?
Like old ladies gathered on a bench.

ANY style of writing/formatting code is good if the author consciously and consistently sticks to it.
Any claims to enforce "standards", whatever and wherever, should be opposed.
Everything what is too simple to read makes you stupid, beware.

Everyone of us experienced SPSSers here has developed their own gorgeous style and, after many years, won't change for another. So why discussing spooks?

[David Marso]

Meow!!!
I guess I/we would say that your code Kirill is extremely readable! *NOT*.
You have mastered the art of obfuscation. ;-))
And yes, I do enjoy discussing that crap.
Take a look under my kilt and you will see I am not an old lady ;-)))))
"ANY style of writing/formatting code is good..."
Well, I/we beg to differ.  Some styles are simply atrocious despite any sort of consistency!

Cheers, David

Kirill Orlov wrote

(Just one bark from behind the corner)
Art, Jan, David,
Do you really find pleasure in lengthily discussing that crap?
Like old ladies gathered on a bench.

ANY style of writing/formatting code is good if the author consciously
and consistently sticks to it.
Any claims to enforce "standards", whatever and wherever, should be opposed.
Everything what is too simple to read makes you stupid, beware.

Everyone of us experienced SPSSers here has developed their own gorgeous
style and, after many years, won't change for another. So why discussing
spooks?

[Albert-Jan Roskam]

>Subject: Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different casing of a variable and to  cross reference variables
>
>(Just one bark from behind the corner)
>Art, Jan, David,
>Do you really find pleasure in lengthily discussing that crap?
>Like old ladies gathered on a bench.


==> hahaha ;-) Do you know the book "Code Complete"? It's all about this topic and it's big enough to serve as a weapon. Now THAT'S a lengthy
discussion.


>ANY style of writing/formatting code is good if the author
    consciously and consistently sticks to it.

===> No. If that author "consciously and consistently" omits comments, uses cryptic variable names and does author coding horror, no then it's not a good idea. I've been reviewing literally thousands of syntaxes for the past months and many, if not the majority, of them were really hard or impossible to understand. Good code should be immediately somewhat understandable for an outsider. If all employees from the same company follow the same standard, their work can be understood by others than themselves. What may be crystal clear for *you* today, will be one big mystery for another researcher later. Art calls this the "lone ranger model" of research. That's a bad idea. Not only for corporate research, but also for PhD projects. Too often, crap gets published in peer-reviewed journals just because the analytical work is done by just one person.


>Any claims to enforce "standards", whatever and wherever, should be
    opposed.
>Everything what is too simple to read makes you stupid, beware.
>
>Everyone of us experienced SPSSers here has developed their own
    gorgeous style and, after many years, won't change for another. So
    why discussing spooks?

===> I would. If I see it has benefits, then why not? That's the trick IMHO: choosecandy rather than a stick. Code may be complex, but why make it unnecessarily complicated? Part of the mental burden can be taken away by writing readable code. Then the reviewer is not disentagling spaghetti, but actually looking what you have done. One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

[J. R. Carroll]

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

Amen!  =P

I second this - what coding standard has ever been enforced?!  I don't remember Python ever commissioning their own SEAL Team 6 to covertly assassinate anyone who uses semicolons at the end of a line in python.  =P

David, you ha said last night that we would never get consensus on a standard because everyone has their own... We don't need capitulation or conformity en masse, that's not the point of a standard (to force others to change their ways).  At least it's not IMO. You "old" guys have learned via trial an error - and us "new" guys would love to learn from your mistakes/observations.  V1.0 of any standard created would just be a guide to help others at writing clearer syntax, and for any developers/shops out there, like mine, to choose to adopt that standard for the purposes of linting or setting the culture with my peers in regards to how SPSS should be developed with/on. 

Sent from my iPhone

On May 13, 2013, at 7:18 AM, Albert-Jan Roskam <[hidden email]> wrote:

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

[Albert-Jan Roskam]

<snip>

>>  /** Yes to all except  SET PRINTBACK=ON.
>>  I use  SET PRINTBACK=OFF to shield users from TMI.
>>  In fact I use OMS to wipe the notes from matrix code unless user specifies
>>  some level of debug.
> *
>>
>>  Use comments and keep them up-to-date
>>  Use inline comments sparingly
> *
>>  /** I tend to use a lot of inline comments.  Why is doing otherwise a bad
>>  idea?

Lots of (long) inline comments give the code a cluttered appearance IMHO.
It could also indicate that comments are compensating for code that itself could be written more clearly.
select if (gender eq 2).  /* select males.
versus:
select if (valuelabel(gender) eq "male").

>>  I have looked at my current project code (~ 2000 lines, only about 1000
>>  are executable ie I comment the hell out of my work)
> *
>>
>>  Use white space to divide coherent blocks of code
> *
>>  /** YES!!!
> *
>>
>>  Use meaningful variable names (!!!!!!!!!!!!) <-- the first commandment
> *
>>  /** and second and third

;-)) so True!

>>  Use ALL CAPS for constants
> *
>>  /** What is a constant in SPSS?

for instance, REFERENCE_YEAR. Sometimes one might need to define it
as compute REFERENCE_YEAR = 1970.
Or (see also magic numbers):
define !REFERENCE_YEAR () 1970 !enddefine.

I forgot to add that one: macros start with an exclamation mark.

> *
>>
>>  Replace magic numbers with mini macrosUse 79 chars max per line (+ a
>>  newline). Readable and printable code!
>>  Indent continued lines (for e.g. VALUE LABELS) so it's batch, not
>>  interactive style syntax.
> *
>>  /** Code should be runnable in both batch and interactive.
> *
>>  Boolean vars start with 'is'
> *

For example:
compute isMale = (valuelabel(gender) eq "male").
select if (isMale).

> *
>>
>>  Embedded SQL in caps
>>  Maybe: use 'eq' for comparisons, and '=' for assignments.
> *
>>  /** Yeah.  That is one of Art's soapbox things.  I tend to agree and
> try
>>  to be consistent.
> *
>>
>>  sparse is better than dense (no: compute z=x>y; yes: compute z_coord =
>>  x_coord > y_coord)
>>  Use EXECUTE sparingly (only after LAG, MISSING VALUES and a few other
>>  cases).
>>  Use $sysmis sparingly.
>>  Use char.* instead of the old string commands In SPSS v21 unicode mode now
>>  is the default!)
>>
>>  /** If writing for potential stoned age versions CHAR. is not an option.
> *

That's true. In that case, unicode mode and .zsav and other stuff is also out of the question.


>>  /** Rather than EXECUTE I would opt for something informative such as
>>  FREQ.

As long as it remains clear that the code breaks if the data pass gets lost, e.g.
frequencies education. /* remove this and this code will explode.

> *
>>
>>  Divide syntax into meaningful units (-->INSERT). 1500-2000 lines of code
>>  is a good maximum amount per syntax.
>>
> *
>>  /** Agree for the most part except then you either need to have access to
>>  the users disk system.
>>  I would prefer that my code be ignorant of that and don't trust the end
>>  user to RTFM to competently define the FILE HANDLES etc.

As long as they don't use drive letters! Sometimes using an envrionment variable is also an option.
I personally also never use relative paths.


>>  No more than four nesting levels (e.g. DO IFs)
> *
>>  /** Sometimes impossible if building really complex code.  If it gets too
>>  deep I bust into a MACRO call.

Agree.

<snip>

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

[Arthur Kramer]

I will be out of my office untilMay 15, 2013.

[Kirill Orlov]

Jan,
Your reasoning is clear, and you shouldn't have brought it home to me. Still, "lone ranger model" is esthetically closer to me personally than "corporate standard model". I've got an innate disregard to things that aim to make "life easier", "people happier", "communication agreeable". That's why I felt like vomit at that "lengthy discussion" among you, please forgive for my burst out.

David,
I admit that my code is a bit compact, nevetherless when commented it is quite understandable. I comment my code for myself in russian; commenting it in english would be waste of time since 1) I'm not very well in english, 2) usually I don't address my code to programmers like you, just to users (When otherwise, I comment my code, e.g. here http://www.spsstools.net/Syntax/RankingLargestValSortingGrouping/VariousAlgorithmsToSortWithinCases.txt).

[Jon K Peck]

Here are the "official" Python coding standards.  (Point of clarification: the inventor of Python is Dutch - it's not a reference to Albert-Jan.)

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: [phone]




From:        "J. R. Carroll" <[hidden email]>
To:        [hidden email],
Date:        05/13/2013 05:39 AM
Subject:        Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different              casing of              a variable and to  cross reference variables
Sent by:        "SPSSX(r) Discussion" <[hidden email]>

---

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

Amen!  =P

I second this - what coding standard has ever been enforced?!  I don't remember Python ever commissioning their own SEAL Team 6 to covertly assassinate anyone who uses semicolons at the end of a line in python.  =P

David, you ha said last night that we would never get consensus on a standard because everyone has their own... We don't need capitulation or conformity en masse, that's not the point of a standard (to force others to change their ways).  At least it's not IMO. You "old" guys have learned via trial an error - and us "new" guys would love to learn from your mistakes/observations.  V1.0 of any standard created would just be a guide to help others at writing clearer syntax, and for any developers/shops out there, like mine, to choose to adopt that standard for the purposes of linting or setting the culture with my peers in regards to how SPSS should be developed with/on.


Sent from my iPhone

On May 13, 2013, at 7:18 AM, Albert-Jan Roskam <fomcl@...> wrote:

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

[King Douglas]

Thanks, Jon!

 

King Douglas

 

From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Jon K Peck
Sent: Monday, May 13, 2013 7:31 AM
To: [hidden email]
Subject: Re: Looking for PYTHONs to read syntax find different casing of a variable and to cross reference variables

 

Here are the "official" Python coding standards.  (Point of clarification: the inventor of Python is Dutch - it's not a reference to Albert-Jan.)

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: [phone]




From:        "J. R. Carroll" <[hidden email]>
To:        [hidden email],
Date:        05/13/2013 05:39 AM
Subject:        Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different              casing of              a variable and to  cross reference variables
Sent by:        "SPSSX(r) Discussion" <[hidden email]>

---

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

Amen!  =P

I second this - what coding standard has ever been enforced?!  I don't remember Python ever commissioning their own SEAL Team 6 to covertly assassinate anyone who uses semicolons at the end of a line in python.  =P

David, you ha said last night that we would never get consensus on a standard because everyone has their own... We don't need capitulation or conformity en masse, that's not the point of a standard (to force others to change their ways).  At least it's not IMO. You "old" guys have learned via trial an error - and us "new" guys would love to learn from your mistakes/observations.  V1.0 of any standard created would just be a guide to help others at writing clearer syntax, and for any developers/shops out there, like mine, to choose to adopt that standard for the purposes of linting or setting the culture with my peers in regards to how SPSS should be developed with/on.


Sent from my iPhone

On May 13, 2013, at 7:18 AM, Albert-Jan Roskam <[hidden email]> wrote:

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

[J. R. Carroll]

Jon,

What's your take on the "community" developing their own standard?  Does IBM have anything "in-house" that dictates how syntax should or shouldn't be written - or are do you just reference the syntax guides/howtos already written for SPSS?

Sent from my iPhone

On May 13, 2013, at 8:31 AM, Jon K Peck <[hidden email]> wrote:

Here are the "official" Python coding standards.  (Point of clarification: the inventor of Python is Dutch - it's not a reference to Albert-Jan.)

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: [phone]




From:        "J. R. Carroll" <[hidden email]>
To:        [hidden email],
Date:        05/13/2013 05:39 AM
Subject:        Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different              casing of              a variable and to  cross reference variables
Sent by:        "SPSSX(r) Discussion" <[hidden email]>

---

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

Amen!  =P

I second this - what coding standard has ever been enforced?!  I don't remember Python ever commissioning their own SEAL Team 6 to covertly assassinate anyone who uses semicolons at the end of a line in python.  =P

David, you ha said last night that we would never get consensus on a standard because everyone has their own... We don't need capitulation or conformity en masse, that's not the point of a standard (to force others to change their ways).  At least it's not IMO. You "old" guys have learned via trial an error - and us "new" guys would love to learn from your mistakes/observations.  V1.0 of any standard created would just be a guide to help others at writing clearer syntax, and for any developers/shops out there, like mine, to choose to adopt that standard for the purposes of linting or setting the culture with my peers in regards to how SPSS should be developed with/on.


Sent from my iPhone

On May 13, 2013, at 7:18 AM, Albert-Jan Roskam <[hidden email]> wrote:

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

[J. R. Carroll]

And... For anyone that likes "Easter Eggs", the poem below is officially referenced as PEP-20, but you can also see it by importing a module called "this"

>>> import this

"The Zen of Python"

[...]

Sent from my iPhone

On May 13, 2013, at 8:31 AM, Jon K Peck <[hidden email]> wrote:

Here are the "official" Python coding standards.  (Point of clarification: the inventor of Python is Dutch - it's not a reference to Albert-Jan.)

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: [phone]




From:        "J. R. Carroll" <[hidden email]>
To:        [hidden email],
Date:        05/13/2013 05:39 AM
Subject:        Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different              casing of              a variable and to  cross reference variables
Sent by:        "SPSSX(r) Discussion" <[hidden email]>

---

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

Amen!  =P

I second this - what coding standard has ever been enforced?!  I don't remember Python ever commissioning their own SEAL Team 6 to covertly assassinate anyone who uses semicolons at the end of a line in python.  =P

David, you ha said last night that we would never get consensus on a standard because everyone has their own... We don't need capitulation or conformity en masse, that's not the point of a standard (to force others to change their ways).  At least it's not IMO. You "old" guys have learned via trial an error - and us "new" guys would love to learn from your mistakes/observations.  V1.0 of any standard created would just be a guide to help others at writing clearer syntax, and for any developers/shops out there, like mine, to choose to adopt that standard for the purposes of linting or setting the culture with my peers in regards to how SPSS should be developed with/on.


Sent from my iPhone

On May 13, 2013, at 7:18 AM, Albert-Jan Roskam <[hidden email]> wrote:

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

[Art Kendall]

Jon, this Zen is very much what I try to do, It is certainly expressed more eloquently.

I am going to start a new thread with a re-expressed request.
On 5/13/2013 8:32 AM, Jon K Peck [via SPSSX Discussion] wrote:

Here are the "official" Python coding standards.  (Point of clarification: the inventor of Python is Dutch - it's not a reference to Albert-Jan.)

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: [phone]




From:        "J. R. Carroll" <[hidden email]>
To:        [hidden email],
Date:        05/13/2013 05:39 AM
Subject:        Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different              casing of              a variable and to  cross reference variables
Sent by:        "SPSSX(r) Discussion" <[hidden email]>

---

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

Amen!  =P

I second this - what coding standard has ever been enforced?!  I don't remember Python ever commissioning their own SEAL Team 6 to covertly assassinate anyone who uses semicolons at the end of a line in python.  =P

David, you ha said last night that we would never get consensus on a standard because everyone has their own... We don't need capitulation or conformity en masse, that's not the point of a standard (to force others to change their ways).  At least it's not IMO. You "old" guys have learned via trial an error - and us "new" guys would love to learn from your mistakes/observations.  V1.0 of any standard created would just be a guide to help others at writing clearer syntax, and for any developers/shops out there, like mine, to choose to adopt that standard for the purposes of linting or setting the culture with my peers in regards to how SPSS should be developed with/on.


Sent from my iPhone

On May 13, 2013, at 7:18 AM, Albert-Jan Roskam <[hidden email]> wrote:

One last thing about coding standards: they are not to be followed as a religion! They're a means, not a goal in themselves.

---

If you reply to this email, your message will be added to the discussion below:

http://spssx-discussion.1045642.n5.nabble.com/Looking-for-PYTHONs-to-read-syntax-find-different-casing-of-a-variable-and-to-cross-reference-variabs-tp5720193p5720210.html

To start a new topic under SPSSX Discussion, email [hidden email]
To unsubscribe from SPSSX Discussion, click here.
NAML

[Albert-Jan Roskam]

_______________________________

> From: J. R. Carroll <[hidden email]>
>To: [hidden email]
>Sent: Monday, May 13, 2013 3:00 PM
>Subject: Re: [SPSSX-L] Looking for PYTHONs to read syntax  find different casing of a variable and to  cross reference variables
>
>
>
>And... For anyone that likes "Easter Eggs", the poem below is officially referenced as PEP-20, but you can also see it by importing a module called "this"
>
>
>>>> import this

Off-topic: The source code is kind of fun

>>> import this, inspect
....

>>> print inspect.getsource(this)
s = """Gur Mra bs Clguba, ol Gvz Crgref

Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""

d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i+c)] = chr((i+13) % 26 + c)

print "".join([d.get(c, c) for c in s])

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD