Philippe BERNERY wrote:
Le 23 avr. 07 à 18:23, Vadim Lebedev a écrit :
- You wrote a tolowercase method, which exists in the String class
of owutil. You should use this method instead of using yours
You're right,
meanwhile i've spent week-end browsing through boost docs, and i've found
in <strings/algorithm.hpp> with wonderful collection of string
related functions.
for example there is a to_lower function which perfomance-wise is
much better than
String::tolowercase. I suppose you're will not object if i'll use it.
or un-cased find function which is better proposition than double
call to tolowercase and search
Ok so should better change code in String::toLowerCase to use this
method instead so it will benefit all code.
I agree that it could be good idea to modify String class to better
use boost,
i don't wish to do it right now because for the moment i don't want to
touch existing functionality.
My patch adds new fucntionality without interfiring with the rest of
wengophone.
Btw, all these functions in boost/algorithm/string.hpp makes the
reasons for existens of String class somewhat
moot.
- There is a struct definition/declaration in sendSmsMessage method.
To keep WengoPhone coding standards, you should declare/define it
outside the method (you can keep it in the .cpp file), and declare
it as a "class" with public methods.
I disagree here. I believe it is a mistake to have ALL of classes
to be in global namespace it simply
augments chances of name conflict.
In this specific case the 'struct builder' is a functional object
which is not intended to be used anywhere
else but only inside sendSmsMessage function. There is no reason
whatsoever to put it into global name space.
As to usage of 'struct' instead of 'class' it is simple issue of
NOISE/SIGNAL ratio. If i wrote 'class'
i'll have to add 'public:' in the class body. Which would confer
no additional information nor functionality.
As I told before the 'struct builder' is for local consumption only,
so if we can achieve the same result with
less text it is better.
If you intend to use it only in this method, I agree this could stay
in the method.
However, still because I care about keeping a coding style in
WengoPhone, you should use the class keyword to define it.
Ok, first I don't want to start the flame war about this struct/class
issue so i did modify per your wishes.
Second on the coding style:
One must not forget that the original reason of existence of coding
style is to cut maintenance costs.
There is really no other TECHNICAL reasons. So the rules that simplify
maintenance are GOOD and
rules that complicate maintenance are BAD.
Maintenance costs are influenced by a lot of factors -- modularity,
cohesion, doc quality are the few very well known to name.
There are factors which attract much less attention in the litterature
and educational system and one of them
is SIGNAL to NOISE ratio. When you need to study a BIG chunk of code,
you're in much better position
when you're not drowned in textual noise. For this reason comment
templates before function decalrations
are actually not a GOOD thing. It is much better to have couple of
phrases of comments in free-flow format
in 2-3 lines, than a 'beautiful' comment templates on half a page, which
often make impossible to see
the comment and function body together on the monitor. ( Of course there
is another reason to use comment templates and it's name 'Doxygen' so
i'll have to live with them :(.... )
Pretty often there are non-technical reasons involved with coding style
rules. One is personal ego of people
who establishes the rules. They decided that such a such way is the best
because what they like them, and they
don't support discussions on the subject. In closes source projects
this almost always the situation.
In open source projects people are more flexible (sometimes no though).
I've personally been involved in establishing coding style rules for
some really big projects, with REALLY BIG EGOS
involved (mine including). And whatever are the rules there are ALWAYS
people which are not satisfied. And when
coders are not satisfied they becomes much less efficient.
So with the time i've devised what i believe the optimal approach to
coding style rules:
1) Publicly visible files (module interface *.h for example) follow
whatever coding style rules are established for the project.
2) Internal files follows the coding style of the original author.
3) Project coding style rules are not carved in the stone, people may
propose modifications which are accepted/rejected by majority vote.
The outcome of this approach, is that it does not hampers personal
creativity of the coders and leaves them
experimentation space, so they could learn and try new things.
So how about to try my approach for openwengo?
Ouff, i was in the teaching mood today.
Btw, i'm attaching the new 'boostified' version of my patch.
Thanks
Vadim
--
Philippe BERNERY <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
http://dev.openwengo.org
_______________________________________________
Wengophone-devel mailing list
[email protected]
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
