From: Lawrence D'Oliveiro on 30 Mar 2010 19:32 In message <hosnrh$6na$1(a)news.eternal-september.org>, Alf P. Steinbach wrote: > This is just unsubstantiated opinion, but worse, it makes a tacit > assumption that there is "best" way to do indentation. However, most > programmers fall into that trap, and I've done it myself. Having used so many different languages over the years, I have settled on a reasonably common set of indentation conventions that work across most of them. The only one that currently annoys me is JavaScript, because its semicolons- are-optional rule means that certain ways I write statements continued across multiple lines are interpreted as prematurely completing the statement. In revenge for that, I refuse to put optional semicolons in my JavaScript code altogether. > I may or may not have been responsible for the similarly impractical > compromise convention of using three spaces per indentation level. At > least, in one big meeting the question about number of spaces was raised > by the speaker, and I replied from the benches, just in jest, "three!". > And that was it (perhaps). I use four. Why four? Because it's divisible by two. Because I use the half- step (two columns) for lines containing nothing but bracketing symbols: for (i = 99; i > 0; --i) { printf("%d slabs of spam in my mail!\n", i); printf("%d slabs of spam,\n", i); printf("Send one to abuse and Just Hit Delete,\n"); printf("%d slabs of spam in my mail!\n\n", i - 1); } /*for*/ for i := 99 downto 1 do begin writeln(i, " slabs of spam in my mail!"); writeln(i, " slabs of spam,"); writeln("Send one to abuse and Just Hit Delete,"); writeln(i - 1, " slabs of spam in my mail!\n\n") end {for} Actually this looks like another opportunity for a loop-with-exit-in-the- middle: for (i = 99;;) { printf("%d slabs of spam in my mail!\n", i); printf("%d slabs of spam,\n", i); printf("Send one to abuse and Just Hit Delete,\n"); --i; if (i == 0) break; printf("%d slabs of spam in my mail!\n\n", i); } /*for*/
From: Steve Holden on 30 Mar 2010 20:12 Jonathan Hayward wrote: > I've posted "Usability, the Soul of Python: An Introduction to the > Python Programming Language Through the Eyes of Usability", at: > > http://JonathansCorner.com/python/ > > The basic suggestion is that much of what works well in Python has > something to do with the usability it offers programmers. > > Enjoy. > Now try another one called "Brevity, the Soul of Technical Writing: An Introduction to Making Yourself Understood Through the Eyes of Readability". What I managed to read seemed to be making worthwhile points, but I felt a bit like I was wading through a steaming pile of irrelevant verbiage that actually made it more difficult to extract the useful nuggets. Bravo for undertaking this task, but I do feel the treatment needs work from a good copy editor. Of course you have to take into account my allergy to folksy metaphors and meandering discourse. Had I chosen your style I might instead have written the criticism above as: """ I would like to begin my critique of this paper with a feature that many competent technical writers completely fail to appreciate: why brevity is desirable in technical writing. Technical writing is not, of course, the only form of writing that there is. People have been writing ever since the first caveman decided he could leave marks on the wall of a cave to indicate that food could be had in the vicinity. The basic concept of brevity is that you should not, as a writer, use superfluous words because if you do then the reader will always be in doubt about which parts of your discourse are meaningful and which are merely decoration. .... """ And so on. As I say, this may be criticism dictated by my personal taste, but I feel you could condense the presentation considerably to good effect. Sorry if this offends. It's meant to help. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
From: Cameron Simpson on 30 Mar 2010 21:04 On 30Mar2010 10:25, Chris Colbert <sccolbert(a)gmail.com> wrote: | not really, the int will eventually overflow and cycle around ;) | | On Tue, Mar 30, 2010 at 8:11 AM, Xavier Ho <contact(a)xavierho.com> wrote: | | > Did no one notice that | > for(i = 99; i > 0; ++i) | > Gives you an infinite loop (sort of) because i starts a 99, and increases | > every loop? And here we see the strength of the Usability example; in Python it won't overflow, rather seguing seamlessly into an increasing expensive arbitrary sized int. Though most machines will eventually run out of memory to hold it... -- Cameron Simpson <cs(a)zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Surely it was of this place, now Cambridge but formerly known by the name of Babylon, that the prophet spoke when he said, 'the wild beasts of the desert shall dwell there, and their houses shall be full of doleful creatures, and owls shall build there, and satyrs shall dance there.' - Thomas Gray (1716-1771)
From: John Nagle on 31 Mar 2010 14:05 Alf P. Steinbach wrote: > * Jean-Michel Pichavant: >> John Nagle wrote: >>> Jonathan Hayward wrote: >>>> I've posted "Usability, the Soul of Python: An Introduction to the >>>> Python Programming Language Through the Eyes of Usability", at: >>>> >>>> http://JonathansCorner.com/python/ >>> >>> No, it's just a rather verbose introduction to Python, in dark brown >>> type on a light brown background. One could write a good paper on this >>> topic, but this isn't it. >>> >>> >>> John Nagle >> Why is it bad ? > > Consider > > > <quote> > From a usability standpoint, the braces go with the lines to print out > the stanza rather than the for statement or the code after, so the > following is best: The last time I ran a C++ project, I just had everyone run their code through Artistic Style ("http://astyle.sourceforge.net") with "--style=ansi". No more inconsistencies. John Nagle
First
|
Prev
|
Pages: 1 2 3 Prev: Matplotlib patches collection + alpha face Next: decorators only when __debug__ == True |