Re: [Rbopensource-developer] Hello?

[Frank B. <bit...@gs...>]

Fabian Rueger wrote:
> =

> Is this list already dead? Just checking... BTW, one of the mroe
> interesting issues was that the list mailer refused to accept my
> mails until I set up a mail account called mailmaster or some such,
> which seems to be part of the SMTP specs. Seems sourceforge is really
> keen on sticking to the standards. No mailer I've used elsewhere
> required this.

Hi Fabian,

no it is not dead, but apparently sleeping ;)

I guess you are speaking about a Postmaster account... no, that is
neither part of the SMTP specs, nor actually required by SourceForge.
But it is a de facto standard that every domain with mail exchanger
should (must?) have a postmaster acoout - this is where spam complaints
etc. usually go to. I'd like to know what happened, since maybe that
could be the reason for the "quiteness" on this list. Maybe you want to
contact me off-list about this.

Now for your other message... I didn't jump in right away since I'd like
the other members of this group to participate a little.

Anyway...
> So, just a question as this thing is slowly developing: How many are =

> we now on this list? =


The mail list has currrently 26 members. But only three of them are
registered as developers. Guys, please remember, even if you have
nothing to contribute but a suggestion what the group could develop -
speak up!

> I was thinking we might need some sort of =

> guideline on how we approach open-sourced projects in terms of :
> =

> - licenses
> - documentation (I think it'd be great if we would find some form of =

> code documentation standard that reflects RB's ease of use
> - source code standard (standardized ways of naming classes, vars, etc)=


I agree, although we shouldn't over-regulate it, or make any of the
rules mandatory.

For stuff we develop and publish under this SourceForge group, we are
bound to the LGPL license. But if someone wants to apply a different
license to a project (s)he initiates, no problem, there are ways we can
do that. =


> I'd volunteer to write up a white paper (or is that blue? green?)

I suggest to make it white, so we can color it later ;)

> for =

> this (open to changes comments etc of course) on how the general =

> process should work. There've been too many attempts imho on getting =

> similar groups off the ground for standardized open RB code, and one =

> of the reasons why they failed I think was the lack of proper =

> procedures (no, I'm not a fan of bureaucracy, it's just that it helps =

> with code).

Yup, a starting point would be cool. I suggest as soon as you have
something, we publish it on the group, so that everybody can comment on i=
t.

> To add to this, I'm not a fan of abbreviated variable and property =

> names. While naming conventions like "cPoint" might suggest that this =

> is a Point class, it makes code reading ugly. I've always thought =

> that one of the major advantages of good Basic code is it's =

> user-friendly human language. E.g., when I have a class that has a =

> property to store ftp-passwords, I won't name that property "psswrd" =

> but "FTPpassword", simply because when I read the code again two =

> years later, I can immediately see what's going on.  I know everybody =

> is used to a different system with this, but for joint open source =

> projects it's really vital to have a working system, and the more =

> explicit it is the better.

As a matter of facct, I'm using naming conventions heavily - but I
change them too often to be of any use ;) So a guideline or list of
suggestions woulld really be good.

Personally, I'm a fan of using descriptive names, too; and I like the
approach of prefixing local variables and properties with a letter that
describes the type. This also helps with the autocomplete feature; if
you have an array of strings "listItems", and an integer
"listItemCount", autocomplete doesn't help you much. But with
"asListItems" and "iListItemCount", you're better off. And I believe in
starting class names with Uppercase letters and other variables with
lowercase; while RB isn't case sensitive, it healps for readability.

But these are just a few suggestions; I guess if you write an outline we
would have something to discuss - and keep this list going.

Cheers,
   Frank+++

--
G=FCnter Schmidt & Co. oHG         =

Frank Bitterlich             eMail: bit...@gs...
Schlosserstr. 2-4            WWW:   http://www.gsco.de/gsco
D-60322 Frankfurt            Tel.:  069 / 156809-29
GERMANY                      Fax:   069 / 156809-28