1. naming convention
- Posted by jacques deschênes <desja at g?obetrott?r.net>
Apr 17, 2008
-
Last edited Apr 18, 2008
As we are talking about a standard library, it is the occasion to introduce some
naming convention that would reduce naming clash. The idea of making it as short
as possible for the economy of some keystrokes is not a good idea at the end.
A look at what is done with other project could be inspiring.
for exemple the gtk project prefix all global with library name like:
gtk_
glib_
etc
Jacques Deschênes
2. Re: naming convention
- Posted by Jeremy Cowgar <jeremy at c?wgar.c?m>
Apr 17, 2008
-
Last edited Apr 18, 2008
jacques deschênes wrote:
>
> As we are talking about a standard library, it is the occasion to introduce
> some naming convention that would reduce naming clash. The idea of making it
> as short as possible for the economy of some keystrokes is not a good idea at
> the end.
> A look at what is done with other project could be inspiring.
>
> for exemple the gtk project prefix all global with library name like:
> gtk_
> glib_
> etc
I'm not quite sure I follow. Can you expand a bit? I too dislike cryptic names
but also dislike string_split_by_char("John Doe", " "). I would strive for a
happy medium, but I am open to suggestions. The current functions are all lower
case and separated by an underscore where needed. I was going to follow suite but
I do not think that's what your speaking of.
--
Jeremy Cowgar
http://jeremy.cowgar.com
3. Re: naming convention
- Posted by Matt Lewis <matthewwalkerlewis at gmail.c??>
Apr 17, 2008
-
Last edited Apr 18, 2008
jacques deschênes wrote:
>
> As we are talking about a standard library, it is the occasion to introduce
> some naming convention that would reduce naming clash. The idea of making it
> as short as possible for the economy of some keystrokes is not a good idea at
> the end.
> A look at what is done with other project could be inspiring.
>
> for exemple the gtk project prefix all global with library name like:
> gtk_
> glib_
> etc
I disagree. I think that the namespace and general conflict resolution in
the next version of euphoria is much more useful, and will handle this sort
of thing much better.
Matt
4. Re: naming convention
Jeremy Cowgar wrote:
> I'm not quite sure I follow. Can you expand a bit? I too dislike cryptic names
> but also dislike string_split_by_char("John Doe", " "). I would strive for a
> happy medium, but I am open to suggestions. The current functions are all
> lower
> case and separated by an underscore where needed. I was going to follow suite
> but I do not think that's what your speaking of.
Just my 0.02 cents (that's 0.0002$),
In my own Eu projects, because Eu do not have a neat namespace feature,
I usually named my function with combination of _ and camelCase.
So, if I were to make replace all function for strings library, I will use
a name like str_replaceAll instead of replaceAll or replace_all or
str_replace_all. Then str_indexOf, str_lastIndexOf. The same goes for hash,
math, dll, struct, date etc. Like hash_put, date_getSecond, etc.
How if we follow Java API for those standard packages? (vector, hash,
set, date, pattern (regex), etc) I think Java API is tested by time and by
users, and the design is quite great.
When I create Eu program now, I almost always use my standard include file.
Unfortunately not every people wants to write their own standard include file.
5. Re: naming convention
Yes it is what I meant in my comment, I like that style. its no more trouble
than the use of:
incluse string.e as str
str:foo()
Reading the code one knows from which library the identifier come from and at
the same it tell the nature of data object on which it work.
for exemple str_split() tel us that it is from string library and at the same we
knows that it work on string. The more a function name tell about itself the less
one need to comment is code.
Jacques Deschênes
Aku wrote:
>
> Jeremy Cowgar wrote:
> > I'm not quite sure I follow. Can you expand a bit? I too dislike cryptic
> > names
> > but also dislike string_split_by_char("John Doe", " "). I would strive for a
> > happy medium, but I am open to suggestions. The current functions are all
> > lower
> > case and separated by an underscore where needed. I was going to follow
> > suite
> > but I do not think that's what your speaking of.
>
> Just my 0.02 cents (that's 0.0002$),
>
> In my own Eu projects, because Eu do not have a neat namespace feature,
> I usually named my function with combination of _ and camelCase.
>
> So, if I were to make replace all function for strings library, I will use
> a name like str_replaceAll instead of replaceAll or replace_all or
> str_replace_all. Then str_indexOf, str_lastIndexOf. The same goes for hash,
>
> math, dll, struct, date etc. Like hash_put, date_getSecond, etc.
>
> How if we follow Java API for those standard packages? (vector, hash,
> set, date, pattern (regex), etc) I think Java API is tested by time and by
> users, and the design is quite great.
>
> When I create Eu program now, I almost always use my standard include file.
>
> Unfortunately not every people wants to write their own standard include file.
