5 ms·

The variable names thing really annoyed me too - a habit of code golf, and people who were originally trained in an old FORTRAN edition that had a 6 or 7 char l

The variable names thing really annoyed me too - a habit of code golf, and people who were originally trained in an old FORTRAN edition that had a 6 or 7 char limit on names.

_wmd 12y ago
Unless you're talking about a large piece of software composed entirely of single character functions and variable names, I pretty much disagree. Verbose variable names do not magically teach those reading a piece of code how it works, simultaneously they tend to make it impossible to write many kinds of expressions concisely, and consequently they regularly damage the readability of more complex pieces of code (e.g. arithmetic expressions involving 3 or more terms). The same goes for symbolic constants. Sometimes (but not exactly "often"), use of numeric literals can vastly improve the maintainability of some code, assuming the reader understands how to maintain it in the first instance. As for increasing reader comprehension, carefully thought out comments are a better mechanism by far. In this case, it is sufficient to know that the file is a compiler/interpreter for its entirety to make sense, assuming the reader has implemented (or at least understood the principles behind) a compiler/interpreter in their past. Expanding the function/variable names, splitting "complicated" expressions out into their own functions, etc., does not magically improve the uninitiated's chance of understanding what is going on
- ajkjk 12y ago
  I mostly strongly disagree. I see no value in naming a variable 'tk', 'pp', or 'bt'. It can only help to make the code more readable with less context. I do not need to understand compilers in detail to know what this program is doing, except, for the names being useless. And if I do understand them but have not spent half an hour or probably much more to digest the exact system by which it operates, I would be completely unable to identify bugs or talk about modifying or extending it in any useful way. Well written comments do not make the code below them more intelligible as text even if they do give you good hints for how to load it into your brain. And "Expanding the function/variable names, splitting "complicated" expressions out into their own functions, etc." all ABSOLUTELY improve the uninitiated's chance of understanding what is going on. Speaking as one of the uninitiated (though I can mostly make out how this works). Man, I wish I knew what 'tk' was. That whole section at line 204 would be so clear if I could follow the intent. I agree with you on symbolic constants and arithmetic though.
  - vajrabum 12y ago
    As you wish. From the program, line 19: tk, // current token
    - tehwalrus 12y ago
      replace all: tk -> current_token
    - ajkjk 12y ago
      yeah, my point is that should be swapped out everywhere. There's no reason not to.
- tehwalrus 12y ago
  Writing expressions concisely is an interesting problem, but in order to do, for example, tensor algebra in C you basically must use macros to define a DSL. It is not a goal which can always be achieved, but structures higher than variable names are what allow one to achieve it (usually.) I didn't say that "verbose" variable names were mandatory everywhere - i and j have their place - but names which are at least pronounceable words are essential, especially if they appear in more places than a five line function. This project is a special case, certainly, but toy compilers are nothing if not to learn from.
emmanueloga_ 12y ago
I used to rather long names too... but now I think short variables have their place, and sometimes they even improve readability. This code seems to follow a lot of conventions (if I see the var "i" I could bet a million dollars is an int that is being used as a counter, probably to go through the positions of an array). It uses plenty of enumerated constants, which is good too. I've been doing some functional programming, where you find that often types are more important than names. See the "Names are overrated" section of this article [1] ( although this point may not apply to this piece of software... C being the language that it is :p). 1: http://techblog.realestate.com.au/the-abject-failure-of-weak-typing/ http://techblog.realestate.com.au/the-abject-failure-of-weak...
- tehwalrus 12y ago
  I'm not against local variables for counting called i and j. I'm against a big list of forward declarations, with tens of different variables, each with a very short name, and a comment explaining what this is an abbreviation for. Just replace the names with the comments, with underscores for spaces, using find and replace. two minute job for the whole code base, much more readable code almost everywhere. I agree that functional languages may be a counter case; but codebases in C and python (in my experience), benefit greatly from well named variables.

The variable names thing really annoyed me too - a habit of code golf, and people who were originally trained in an old FORTRAN edition that had a 6 or 7 char limit on names.

_wmd 12y ago

Unless you're talking about a large piece of software composed entirely of single character functions and variable names, I pretty much disagree. Verbose variable names do not magically teach those reading a piece of code how it works, simultaneously they tend to make it impossible to write many kinds of expressions concisely, and consequently they regularly damage the readability of more complex pieces of code (e.g. arithmetic expressions involving 3 or more terms). The same goes for symbolic constants. Sometimes (but not exactly "often"), use of numeric literals can vastly improve the maintainability of some code, assuming the reader understands how to maintain it in the first instance. As for increasing reader comprehension, carefully thought out comments are a better mechanism by far. In this case, it is sufficient to know that the file is a compiler/interpreter for its entirety to make sense, assuming the reader has implemented (or at least understood the principles behind) a compiler/interpreter in their past. Expanding the function/variable names, splitting "complicated" expressions out into their own functions, etc., does not magically improve the uninitiated's chance of understanding what is going on

ajkjk 12y ago
I mostly strongly disagree. I see no value in naming a variable 'tk', 'pp', or 'bt'. It can only help to make the code more readable with less context. I do not need to understand compilers in detail to know what this program is doing, except, for the names being useless. And if I do understand them but have not spent half an hour or probably much more to digest the exact system by which it operates, I would be completely unable to identify bugs or talk about modifying or extending it in any useful way. Well written comments do not make the code below them more intelligible as text even if they do give you good hints for how to load it into your brain. And "Expanding the function/variable names, splitting "complicated" expressions out into their own functions, etc." all ABSOLUTELY improve the uninitiated's chance of understanding what is going on. Speaking as one of the uninitiated (though I can mostly make out how this works). Man, I wish I knew what 'tk' was. That whole section at line 204 would be so clear if I could follow the intent. I agree with you on symbolic constants and arithmetic though.
- vajrabum 12y ago
  As you wish. From the program, line 19: tk, // current token
  - tehwalrus 12y ago
    replace all: tk -> current_token
  - ajkjk 12y ago
    yeah, my point is that should be swapped out everywhere. There's no reason not to.
tehwalrus 12y ago
Writing expressions concisely is an interesting problem, but in order to do, for example, tensor algebra in C you basically must use macros to define a DSL. It is not a goal which can always be achieved, but structures higher than variable names are what allow one to achieve it (usually.) I didn't say that "verbose" variable names were mandatory everywhere - i and j have their place - but names which are at least pronounceable words are essential, especially if they appear in more places than a five line function. This project is a special case, certainly, but toy compilers are nothing if not to learn from.

emmanueloga_ 12y ago

I used to rather long names too... but now I think short variables have their place, and sometimes they even improve readability. This code seems to follow a lot of conventions (if I see the var "i" I could bet a million dollars is an int that is being used as a counter, probably to go through the positions of an array). It uses plenty of enumerated constants, which is good too. I've been doing some functional programming, where you find that often types are more important than names. See the "Names are overrated" section of this article [1] ( although this point may not apply to this piece of software... C being the language that it is :p). 1: http://techblog.realestate.com.au/the-abject-failure-of-weak-typing/ http://techblog.realestate.com.au/the-abject-failure-of-weak...

tehwalrus 12y ago
I'm not against local variables for counting called i and j. I'm against a big list of forward declarations, with tens of different variables, each with a very short name, and a comment explaining what this is an abbreviation for. Just replace the names with the comments, with underscores for spaces, using find and replace. two minute job for the whole code base, much more readable code almost everywhere. I agree that functional languages may be a counter case; but codebases in C and python (in my experience), benefit greatly from well named variables.