Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Golden California Girls on 27 Feb 2010 17:55 Richard Heathfield wrote: > Ian Collins wrote: >> Richard wrote: > <snip> > >>> It is ludocrous to recommend the second form. ALL it does is waste a >>> line. Indentation is there for a reason. We dont need to see the opening >>> bracket on its own wasted line. >> >> What's the going rate for a line these days? > > People should avoid trying to answer that question until they have > checked their answer in the debugger. > Cost of a line feed is the same as the cost of a space character.
From: Richard Heathfield on 27 Feb 2010 17:59 James Harris wrote: <snip> > > Come to think of it, [...] what do Windows > users use to enter and edit source code? gvim > I don't think I ever use tabs when typing a high level language. I > always use spaces - just two per indent. Ah, at last, a true Scotsman. :-) <snip> -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Jonathan de Boyne Pollard on 27 Feb 2010 17:30 > > > Set tabstop to 2, 3, 4, 5, 8, 179, whatever looks best to your > preferences. > tabs 1,+1,+2,+3,+5,+8,+13,+21,+34,+55,+89
From: Kelsey Bjarnason on 27 Feb 2010 18:06 [snips] On Sat, 27 Feb 2010 00:39:29 -0800, James Harris wrote: >> Three, actually. Okay, 8, if you're stuck using output devices from >> the 1960's which didn't allow user-defined tab spaces, but for how many >> people is this true anymore? > > Windows Notepad users are stuck with 8. Windows Wordpad users seem to be > stuck with 6. These are not earlier than the 1980s. People actually *use* Notepad? For *code*? TextPad, NotePad++, about 1,873,000 other options, and you use *notepad*? Okay, fine, this is a case of blame the tool. The one between the keyboard and the chair. :) > Come to think of it, apart from those two programs what do Windows users > use to enter and edit source code? Endless IDEs. Endless text editors not so crippled. Ones with little things such as auto-indent, or syntax highlighting, or code folding, and a host of other features. > I don't think I ever use tabs when typing a high level language. I > always use spaces - just two per indent. Then there are no portability > problems Unless one is working on your code and someone else's which uses three spaces. Or four. Or eight. In which case it's not merely a mess, but an unrecoverable mess. > IMHO embedded tabs in source code should be consigned to the wastebin of > history as just one of those non-printable characters we used to hate. > Why? Well, they generate a different result depending on where they are > placed and *look like* something else - i.e. one or more spaces. They > are, to an extent, hidden. Which they're meant to be. They're a layout item, not a visible item. Like spaces. Or newlines.
From: Kelsey Bjarnason on 27 Feb 2010 18:15
[snips] On Sat, 27 Feb 2010 07:00:50 +0100, Richard wrote: >> Contrast that to hitting delete on a line which uses spaces instead of >> tabs. All this does is mess up the formatting, as the editor is almost >> certain to treat a space as a _space_, as it should, not as a tab, >> which it _shouldn't_, because the character involved is not a tab, but >> a space. > > Not with any half competent editor. Really. Explain to the class the AI process involved in determining whether a space is actually a space, or one of several spaces masquerading as a tab, and how the editor - in the absence of tab stops - tells the difference between one space, two spaces, one tab's worth of spaces, two tab's worth of spaces... Granted, some will - if you use the tab key to indent/unindent, simply add or remove to the next tab stop's worth, but all you're doing there is using tabs and tab stops and converting to spaces for some as yet unexplained reason. >> Then, of course, there's inserting. Hit space. See how many columns >> the line indents. One, isn't it? Why is that? Oh, yes, because >> spaces aren't tabs, and editors won't treat them as tabs. Tabs are >> tabs, and editors treat them that way. > > And often treat spaces as tabs too. press left or right or delete on y > white space area and it deletes to a tap stop. If I press "delete" in an editor once, and it deletes more than one character, the editor is by definition broken and needs to be fixed or chucked. The only time an editor should _ever_ do more than one thing per keystroke is in the case of a macro or function key. >> AFAIK, even Emacs and vi can cope with tabs. I've yet to meet _any_ > > Even? Emacs is probably the most advanced editor out there. And vi one > of the most popular programmers editor. Which suggests they should be able to cope with tabs. >> Because spaces, for purposes of indentation, are defective by design, >> and > > What total bullshit. Most people use spaces for indentation. Yes, and thus we end up with one piece of code using two spaces, another using three, another using 4, or 5, or 8, and any attempt to make this make sense is doomed to failure - because the whole process is defective by design. >> editors are generally built in such a manner as to use the right thing >> for the right job. Spaces between words, etc, tabs for indentation. >> >> > Totally and utterly wrong. Really? You use editors that can't handle tabs and tabstops? Why would you rely on such crippled tools? > Its rare to find tabs used anymore. Most > editors are LSEs (language sensitive editors) and indent automatically > based on a configured language layout. Which works if - and only if - they're not being overriden by some goober's insistence upon doing the wrong thing by using non-indentation characters for purposes of indentation. Especially true when working with multiple developers and sometihng like CVS, where such auto-mangling, without a de-mangling phase on checkin, simply leads to a chaotic mess. Really, why would anyone want to insist on using the wrong tool for the job? Spaces for indendation, Pascal compilers for C code, makes no sense. |