Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: Sean Kennedy Newsgroups: scea.yaroze.beginners Subject: Re: A few requests Date: Mon, 30 Jun 1997 13:19:09 -0400 Organization: Humber College A.A.T. Lines: 76 Message-ID: <33B7EA89.1726@admin.humberc.on.ca> References: <33788386.949380@205.149.189.29> <3378ED76.408C@charlie.cns.iit.edu> Reply-To: kennedy@moe.acad.humberc.on.ca NNTP-Posting-Host: ratbert.humberc.on.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) 2 cents aside, but... The following is all on who leaned how to program by what means and how.. Ed Federmeyer wrote: > Brian Gilman wrote: > > > Mario wrote: > > > I agree that we need to do several more examples that show the basics, > > > but I'll have to disagree with you on the manuals. I've done some work I found the manuals for the PSX on par with those from current companies supplying the microchips used in the PSX. Limited in documentation scope, they rely on you the programmer to come up to speed on the specific system of doing things. AND that is by no means standard... > One thing that would help the current docs *a lot* would be to include > an example call for each of the functions, and an example of directly > initializing each of the data structures. The example calls might > require > a little bit of surrounding code, but hopefully not much. Hmm, a neat Borland Turbo example thing to do, but dangerous. Here's why: In assembler for one function there are usually six ways of doing the function, depending on what type of coder you are. In C there could be twelve different ways of Initializing the data. By giving no examples at all, the easiest and LAZIEST {we're programmers here, remember that.} method of doing something will always come to the top of the pile. Why? I really cannot be certain except it follows the ASAP philisophy. AS. SIMPLE. AS. POSSIBLE. AS. SOON. AS. POSSIBLE. I hate the KISS method because I may be lazy, but I'm NOT STUPID! {No Fat Chicks, No VBX, AND NO DLL'S!!!} ASAP. > > > Actually, I find that more #defines makes the program easier to read. > > > For example, when setting the scale of a sprite to one, I use the > > > define ONE, not the constant 4096. > > I agree, but that's for my own code. IMHO code is a lot less readable by > > someone other than the coder when lots of #define's are used. > > If there are "standard" defines, they should be mentioned in the docs. > Now I know that ONE means 4096, but at first, I had to take a break from > reading the code to go hunt that down, which breaks the concentration, > which just makes it a bit harder to understand new stuff. Even if the > 'standard' defines are used, it would be good to say /* ONE = 4096 */, > just to help keep the learner focused on learning the subject, not > hunting > down the defines. > > > > That might be nice, but it's going to be pretty hard to get all these > > > programmers scattered around the world to agree on the same standard > > > names. I can only speak for myself, but I try to make the variable > > > names self-explanatory. However, since I don't like to type any more > > > than necessary, I'd probably use WorldOT[]. > > Right, that would be hard. Instead, use search and replace :) > > Since the functions are all "SortOT", "BlahOT", etc, it would make > things > more readable to use "WorldOT", rather than "WorldOrderingTable". > Likewise > for "SortBG", I call my data structure "MyBG" (or whatever). It's very > obvious then that that struct is use with the "WhateverBG" routines. > > EdF Trying to get someone to agree to anything is hard. Getting someone to document something is harder. But, documentation in programming is vital. ASAP --> Not too verbose, Not too sparse. Thais is the difference between good programmers and programmers that work at a large comapany that makes the most used operating system... {ASAP_BAR! for those who know what I'm talking about..} -sean