6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: Lyrical Nanoha on 4 Jun 2006 05:18 On Sun, 4 Jun 2006, Michael J. Mahon wrote: <snips here and there> > It isn't about beauty--it's about clarity. And there are *huge* > payoffs in adopting a standard format for programs--as, indeed, > most serious projects do. I have a format of my own, which I adopted out of necessity - couldn't read my own code when it was all smashed against the left margin! > Not everyone likes to spell words the same way, either, but we > don't care what they think--the convention is king. Of course there is no single convention for C; I use braces on separate lines with an indent of 1 space within the braces, and my function headers are one line - and there is a minimum of whitespace against the last margin but it's fairly readable. > BTW, programmers shouldn't choose names they "like", either. Naming > should all be within a simple, rigid framework, so that the semantics > of any name are expressed by the identifier. I use several metasyntactic names for throwaway variables (foo, bar, grill; travel, travel2, travel3; i, j, k; x, y, z), but usually it's something like "nolin" (number of lines), "curlin" (current line), etc. - an abbreviation, since I don't like to type any more than I have to. -uso.
From: Michael J. Mahon on 4 Jun 2006 06:00 Lyrical Nanoha wrote: > On Sun, 4 Jun 2006, Michael J. Mahon wrote: > > <snips here and there> > >> It isn't about beauty--it's about clarity. And there are *huge* >> payoffs in adopting a standard format for programs--as, indeed, >> most serious projects do. > > > I have a format of my own, which I adopted out of necessity - couldn't > read my own code when it was all smashed against the left margin! There is an almost universal appreciation of the value of syntax- oriented formatting. Of course, essentially all books show examples of such formatting. Capricious or misleading (non-syntactic) formatting would be a disaster--even in a one-person programming team. ;-) >> Not everyone likes to spell words the same way, either, but we >> don't care what they think--the convention is king. > > > Of course there is no single convention for C; I use braces on separate > lines with an indent of 1 space within the braces, and my function > headers are one line - and there is a minimum of whitespace against the > last margin but it's fairly readable. But within a programming project, *someone* will have to define a common convention for all to use--otherwise, there will be lots of errors, and design reviews will be a nightmare. ;-) >> BTW, programmers shouldn't choose names they "like", either. Naming >> should all be within a simple, rigid framework, so that the semantics >> of any name are expressed by the identifier. > > > I use several metasyntactic names for throwaway variables (foo, bar, > grill; travel, travel2, travel3; i, j, k; x, y, z), but usually it's > something like "nolin" (number of lines), "curlin" (current line), etc. > - an abbreviation, since I don't like to type any more than I have to. For a small namespace, simple schemes can be workable, but for large namespaces, with many hundreds of identifiers, naming conventions help keep things straight, avoiding conflicts and, even more importantly, providing instant recognition to a reader who understands the naming convention. -michael Parallel computing for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused."
From: sicklittlemonkey on 4 Jun 2006 07:20 Michael J. Mahon wrote: > Lyrical Nanoha wrote: > > I use several metasyntactic names for throwaway variables (foo, bar, > > grill; travel, travel2, travel3; i, j, k; x, y, z), but usually it's > > something like "nolin" (number of lines), "curlin" (current line), etc. > > - an abbreviation, since I don't like to type any more than I have to. > > For a small namespace, simple schemes can be workable, but for large > namespaces, with many hundreds of identifiers, naming conventions help > keep things straight, avoiding conflicts and, even more importantly, > providing instant recognition to a reader who understands the naming > convention. Saving keypresses in the way LN describes can really waste brain cycles elsewhere. Years ago I tired of the proclivity for programmers to abbreviate into 3 letters even 4 letter words (etc), just to fit a pattern. Those days are long gone for me, and today's IDEs it's easy enough to type the first few letters then ctrl-space to complete the rest. Using "no" within a variable name is confusing, because as we all know, no means no. A "Num" suffix is much clearer IMO. As for foo, bar and other "throwaways", I find there is almost always a better word for such a temporary variable, otherwise just call it what it is "temp". This might seem trivial, but like MM says, get a huge project and watch the "obvious" abbreviations start to collide. Heh, I remember refactoring someone's code, and having to work out what purpose was served by the variable "i_cant_be_bothered_thinking_of_a_f*cking_name_for_this_one". ;-) Cheers, Nick.
From: mdj on 4 Jun 2006 09:45 Michael J. Mahon wrote: > It isn't about beauty--it's about clarity. And there are *huge* > payoffs in adopting a standard format for programs--as, indeed, > most serious projects do. > > Not everyone likes to spell words the same way, either, but we > don't care what they think--the convention is king. > > With proper rules, a program's beauty when expressed in a language > is *precisely* its evident function. > > BTW, programmers shouldn't choose names they "like", either. Naming > should all be within a simple, rigid framework, so that the semantics > of any name are expressed by the identifier. > > The lack of widespread adoption of such a convention is a measure of > the immaturity of programming as a discipline. Oh I completely agree. I just think we're a fair number of years away yet from that level of discipline. A pity. I hope that eventually we'll be dealing with very high abstraction levels, perhaps languages with its own symbology rather than being forced into being expressed in roman character sets, etc. There is a long, long way to go before such ideals are realised though. Fortunately, some people are beginning to see the light. Matt
From: mdj on 4 Jun 2006 09:49
sicklittlemonkey wrote: > Saving keypresses in the way LN describes can really waste brain cycles > elsewhere. Years ago I tired of the proclivity for programmers to > abbreviate into 3 letters even 4 letter words (etc), just to fit a > pattern. Those days are long gone for me, and today's IDEs it's easy > enough to type the first few letters then ctrl-space to complete the > rest. The old formatting 'rule' of not exceeding 80 characters on a line has finally started to die, along with the terminals that encouraged it, which has helped things a great deal. I share your appreciation of IDE's abilities to autocomplete code - the productivity difference is enormous, but then the mental agility lost to not remembering API definitions anymore is a bit of a concern. Matt |