Re: Misc. convention stuff

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>>There's also API inconsistency in terms of design, mainly as a result of
>>the fact that the different parts are largely independent, but I don't know
>>yet how to overcome that (and whether it is neccessary). -> later.
>>
>If this is an issue that is to ever be resolved, then it would have to be
>resolved before too much code has gone from design to code, as this is by
>definition a design issue. It would also be possible to resolve at a later
>point, but that could easily get very messy, forcing the breaking and
>recoding of a lot code if we are unlucky.
>
>If this issue really *needs* to be resolved is another question. There is
>the point that as the various PenguinPlay sub-projects deal with totally
>different problems and gives completely different functionality to the
>client, that they will naturally also have completely different designs.

That's why I added the "later" mark - I'm myself not sure yet what needs to
be done here.

>I think that is a good argument, however, there are some issues that could
>(and should) be resolved in this area. An example could be how to handle and
>manipulate strings. I remember seeing somebody using the standard library
>string class somewhere. Wheter or not to use that class is certainly a thing
>that could be agree upon. Also, I think it would be wise agree upon which
>container classes that are to be used (std lib?), and when to use references
>and when to use pointers, or indeed to use references at all.

good points.

>IMHO, these are important issues that needs to be sorted ASAP. Though
>putting it off a week or two or three won't make everything crash and burn,
>correct, putting it off for *too* long might not be the best course of
>action.

(see my reply to Peter's mail for more)

>>Ok. good point. Possible solution (more or less the current implicit
>>convention): The primary header of each Part (subpart), i.e.
>>Penguin2D.h, PenguinFile.h, ...  - no pp prefix (The Penguin... is enough
>>and it's clearer).
>>All others: pp<partletter> prefix (i.e. "ppf" for PenguinFile, "ppg" for
>>PenguinGraphics, "pps" for PenguinSound).
>
>I think that's a good idea.
>
>btw, are there projects with a prefix longer than 1 character?

By definition not.

>>Again - the goal is readability. I often mix these forms, depending on
>>what's more readable in the specific situation.
>>For example, this:
>>
>>-----
>>int x = strcmp (String1, String2);
>>
>>if      (x > 0) return String1;
>>else if (x < 0) return String2;
>>else            return 0;
>>------
>>
>You find this easy to read? I find it to be very alien to anything I've ever
>seen, thus I don't find it easy to read.

I thought a bit about this issue...
I found that I'm rather often looking through completely different code -
be it the examples in Uni, the code of friends I help to debug, the code of
some MUD that's too unbalanced for my taste, some app that doesn't compile
correctly or something else.
Perhaps because of that I actually don't expect anything from code - except
perhaps that it has *some* recognizable style.


Another thing: One of your arguments for a very consistent style was that
inconsistency would put off potential new developers because they find it
harder to read the code.
But imagine they actually decide to contribute some code and we say -
thanks, that's great - but your code has to follow exactly this style.
Free software developers are volunteers, and about 80% of them would leave
if presented with that choice.



	Christian
--

Drive A: not responding...Formatting C: instead