Sponsor: The CSS Anthology
The CSS Anthology: 101 Essential Tips, Tricks & Hacks (external link)
Blog Entry
Code Syntax Debates in the Programming World
Published on the 29th of October 2008
There are a number of code-syntax debates in the world of programming. Everyone has the common goal of establishing some sort of code-syntax standard so developers can easily work on each others' code, but everyone disagrees on exactly what the standard should be. Some programming languages, like Python, have largely solved this problem by enforcing a specific syntax on developers. However, these syntax debates still exist in many programming communities, such as the PHP developer community, as PHP gives developers a lot of syntax freedom. I thought it would be interesting to see what Lowter members thought about some of the longstanding code syntax debates:
- Indentation style (K&R, Allman, BSD KNF, Whitesmiths, GNU, etc.)
- VariableName, variableName, variablename, or variable_name?
- Spacing around parentheses
- One letter variable naming
- Allowing coding shortcuts and shorthand methods
You can read about all sorts of programming styles (external link) on Wikipedia, but what I've listed here seems to be the differences I most encounter personally. Although the code-syntax debate doesn't look to have an end in the near future, please comment which syntax you support in the comments below!
Comments
-
Frans (external link) (30 Oct 2008 7:26)
I prefer
PHP
<?php
if (isset(variable_name)) {
return true;
} else {
return false;
}
?>My second choice would go towards
PHP
<?php
if (variableName)
{
return true;
}
?>or of course in between possibilities.
In the case of rather long if statements and the like my preference actually tends to go towards something like
PHP
<?php
if (
(bla == blo)
&& (bla == blu)
&& (bla != alb)
) {
return true;
}
?>It also depends on the language. In PHP I like $variable_name, but in Java variableName makes it a tad easier to discern that is is, in fact, a variable. In that regard, a common practice in Java is variableName and ClassName, if I remember correctly; it's been a few years. To deviate from that while writing Java would probably be counter-productive. Also, in Python it's not recommended to use underscores in variable names because it might have a special meaning. I've forgotten the details.
One letter variable names seem counter-productive to me in every situation that involves more than one person, and even then it's probably not the best method. I know that I wouldn't know what variable b was meant to be after a month. I'd have to go back to where I defined the variable where I hopefully remembered to comment what exactly it's supposed to contain. If not commented properly I'd even have to read through a bunch of functions to figure out what exactly said variable did. Some sort of at least semi-descriptive variable name is like a sort of mini-comment every time you use it. Typing speed ought not to be too big of a problem either: as far as I'm aware most, if not all, IDEs offer auto-completion capabilities.
Shorthand methods seem just fine to me. If you're talking DOM, for example, then getElementsById is rather long and in the case of Javascript, wasting bytes if you use it a couple of times. getById or something like that would make the code easier to read imo.
All in all it just comes down to on who you're participating with in the project. Everyone has different personal preferences.
-
Eugene Wee (30 Oct 2008 9:56)
Eh, this is not about syntax, but about style. All programming languages (and languages in general) enforce syntax, but some (e.g., your example of Python) enforce particular stylistic aspects through the use of syntax.
Personally, I am pretty happy with both K&R and Allman for indent style. Likewise, I am pretty happy with both camel case and the use of underscore separators for variable names. I typically do not pad parenthesized expressions with extra spaces, and reserve single letter names for loop indices and certain mathematical expressions where it is already the common convention.
Generally, I subscribe to the notion that it is more important to be reasonably consistent than to be unreasonably dogmatic about style.
"Also, in Python it's not recommended to use underscores in variable names because it might have a special meaning. I've forgotten the details."
PEP-8 disagrees with you, but you are probably thinking about be careful with leading/trailing underscores in variable names.
-
Ethan Poole (external link) (30 Oct 2008 10:34)
Eugune, style is a sub-field is syntax. You code with a style of syntax, even if that particular programming language allows other styles of syntax.
-
Eugene Wee (30 Oct 2008 13:45)
When I say syntax, I mean the grammatical rules of a language, i.e., the form of its expressions, statements and other structural units. It is true that syntax is also a matter of style to the language designer and to a language user who is considering a language, but I distinguish between syntax and style because syntax is generally immutable to a language user, but style can be changed at a language user's discretion.
In other words, a debate on syntax is not just a debate of "I prefer camel case separation to underscore separation for variable names", but "I prefer programming languages that forbid underscore separation variable names so that camel case separation is the only viable choice". Likewise, it is not a question of "K&R, Allman, BSD KNF, Whitesmiths, GNU, etc?" but "free form?"
-
Ethan Poole (external link) (30 Oct 2008 14:30)
I see you're point, but perhaps my point is not clear. While these issues now are style issues, as you have pointed out, I am merely addressing which ones commentors support as what should be the syntax of the language. I hope this makes some sense.
-
Doug (7 Nov 2008 8:33)
I'l going to personally try to switch to camel casing for variable and function names. It's less typing and I can type faster when I use them.
I also use the samefunction declarations as Frans.
Sponsor: Songbird Media Player
Desktop web player, a digital jukebox, and web browser mash-up. (external link)
