Jump to content

Coding Style


Err

Recommended Posts

What's your coding style? I know you code a certain way, but what's your reason behind it? I'm interested in how other people code, esp. Justsomeguy.1. When I indent my code, I use two spaces instead of tabs. This is for all languages. I find the tabs annoying, it indents my code too far to the right causing me to use the side scrollbar.2. I use Lucida Console for my font. It makes the i's, I's, l's, L's, and 1's very distinguishable from each other and since it's a monospace font it helps with proper indenting of code.3. I don't use spaces after the commas in arguments. I feel that the comma already acts as a visual separator, so I just omit the spaces.I have more that I'll post later.

Link to comment
Share on other sites

Most difference probably comes from people's choice of indent style. Of course, the One True Brace style is the only way to write code correctly :)You can always change the tab width in your editor. I find real tabs less fiddly, however historically indentation has been achieved using spaces.I think it is conventional to place spaces after commas, just as you would in English.Fortunately, the choice of font doesn't affect the final code, or anyone else.Most people pick up their coding style from the various books and manuals they read.

Link to comment
Share on other sites

I'm very old-school, I'm afraid.Tabs for indentation. On my system, that's the same as 5 characters, and in a 9pt font it doesn't use up very much real estate.Spaces between arguments and operators. No space between a function and its arguments when it is being called, but generally a space there when the function is declared. A space between multiple closing parentheses. A space between a closing parenthesis and an opening brace. A space before and after // and # comment indicators. I'm pretty fanatic about spaces.I often insert extra spaces or tabs to align operators or R-values when I have a group of semantically related statements. (E.g., when I'm assigning multiple property values to the same object.)For braces, I stick religiously to the 1TBS, even for functions, which is not true K&R, but I like the consistency.Depending on my mood, I'll use grouping parentheses for clarity even when the order of operations doesn't require them.I've been a Macintosh guy since I made the jump from DOS 3.2. The default monospace font on the Mac has been Monaco since 1984, I think, and I still use that. (A proportionately-spaced font would be annoying as he11.) Monaco was designed for clear reading at 9 points on a screen with no anti-aliasing. L, l, i, and 1 are easily distinguished. Serifs are minimal but useful. Not as aggressive as those in Courier, say.I use ternary operators whenever possible because in my mind they read more like sentences.If I have to access an object property or a return value more than once in a function or code block, I assign it to a variable. This is for efficiency as well, but it also makes code more readable.I rarely combine function calls on a single line of code, unless the result is extremely readable, and especially when it's a pattern I use a lot, the sort of thing you find in everyone else's code.For the sake of maintenance, I like self-commenting variable and function identifiers, even when they get long. build_preferences_object() doesn't bother me a bit. (I use camelCase a lot less than I used to, mostly so I can tell my functions from built-in functions.)That said, I will remove spaces, tabs, and returns when size is an issue, and I will shorten identifiers. On some big projects I generate an optimized version of code from my editable version, but I keep the editable version on file.I also have libraries of seriously optimized code where I break most of the rules I just spelled out. I do this when I'm pretty certain that I'll never have to update the code. A simple example:if(!String.prototype.trimRight){String.prototype.trimRight=function(){return this.replace(/\s+$/,"")}};I'm not especially fussy either about HTML that gets generated by PHP or JavaScript. It's there to work, not be looked at.

Link to comment
Share on other sites

You can always change the tab width in your editor. I find real tabs less fiddly, however historically indentation has been achieved using spaces.
I find that multi-tabs sometimes change when I move a file to a different system, even when the platform and software are the same. So I'm using spaces more and more for the sake of alignment. But not indentation. Tab tab tab.
Link to comment
Share on other sites

I like the 1TBS as well, it reads easier than:if(something) {do this}I also like ternary operators, as they are elegant and efficient.With regards to indenting, here is my question: do you guys indent as you go, or do you need to straighten it up at the end? I make so many amendments that by the time I finish, what started as nice indenting has gone completely to pot.

Link to comment
Share on other sites

Indenting as I go keeps me sane. In fact, I like to create empty control structures before I fill them in. So when I'm writing an if/else, I won't put any tests or statements in it until I have it blocked out and correctly indented.I can see what you mean with HTML, though. I often revise the indentation, since I am often updating the precise structure.

Link to comment
Share on other sites

Eh, what's the point of indenting at the end- too late to help you then! You can always indent/outdent multiple lines of code as necessary.

Link to comment
Share on other sites

Obviously, the best way is to have all the code on one line, as few spaces as possible, random variable names and no comments.

var igsd=0;l=document;o='write';do {l[o](igsd);igsd=(igsd+1)*(igsd+2)}while(igsd<(060+0xF));

I like the 1TBS way, and I always use two spaces for indenting. I just don't like having an opening brace on its own line.

Link to comment
Share on other sites

When we talk about PHP, I code with the PEAR coding standards. In other words, braces on a separate line (and always present), brackets on control structures after a space, and without a space for functions. Space after each comma in the arguments list. 4 spaces for identation (but I do press the tab key on my IDE), camel case naming, underscore as a "namespace like" separator and as a prefix for private members, etc.It is worth noting that a lot of those (I think good) practices are deeply integrated into my IDE (NetBeans). As I said, pressing tab results in 4 spaces. Pressing enter puts you back into the same column on the new line, pressing enter after an opening bracket puts on the next line, 4 spaces after the bracket, etc. Therefore, NOT following those standards is now getting harder and harder for me... and thank goodness for that.As for C(++) code, I use Visual Studio which doesn't appear to do that much housekeeping on code appearance (it does a much better job for C#). But I manually do a similar kind of housekeeping manually.For CSS code, I mostly follow the pattern of "selector, space, bracket, new line, tab, (property, space, value, semicolon)+, closing bracket, new line, new line".

Link to comment
Share on other sites

Looks like a lot of us are using variations on K&R. PEAR Style seems to recommend a lot of spaces generally, and the sort of alignment with spaces that I mentioned. I do not understand why you would want to leave spaces out of a list. To me, one of these is much easier to read:(something,25,22,175,false,another)(something, 25, 22, 175, false, another)I also find it easier to place my cursor in the correct spot when I need to edit a thing like that. If you need significant optimization, sure. But that is not an issue for compiled code, insignificant for server-side scripts (HD space is cheap these days) and usually not an issue for simple web pages.I use the 1TBS for functions because I don't have to think about it. I just do the same thing everywhere. I don't need the visual cue to tell me a structure is a function, because all my global functions begin at the first tab stop.I can see the advantage of aligning opening and closing braces. I'm just used to the other way.Anyway, whether to put an opening brace on a new line seems like a trivial difference compared to some of the other brace styles that people use. I can read them ok. I just don't feel like giving up a habit I've used since the 1980s. :)What REALLY drives me nuts is looking at code that noobs post on this board that uses no style at all. Indents and braces placed randomly, etc. If I have to reformat code just to understand it, or to make sure the braces match, there is a problem. Same goes for HTML. Except for one-liners, I expect the opening and closing tags to be aligned. Troubleshooting is so much easier. And, of course, code that doesn't do that tends to have way too many page elements to begin with, which makes the whole thing a ### mess.Interesting that no one's mentioned anything about BEGIN and END markers. Small wonder our styles are so similar. We're obviously using the same languages, and they all have the same ancestor.I am intrigued by the bare style of Python, but style is not a reason to learn a new language.

Link to comment
Share on other sites

Interesting that no one's mentioned anything about BEGIN and END markers. Small wonder our styles are so similar. We're obviously using the same languages, and they all have the same ancestor.
I would put those on the same column, one line below what was before "BEGIN" and one line above what is after "END", and have everything in between be four spaces idented inside. In other words, I'd treat them as equivalents of "{" and "}", respectively.
Link to comment
Share on other sites

Yes, in addition to being competent with bar and guitar tabs, Duane Allman was also a master programmer and influential in coding style. The song "Trouble No More" is about a late-night debugging session, while "Whipping Post" describes Duane's implementation of the Towers Of Hanoi problem, and "One Way Out" is really a discussion about A* search.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...