Re: attack of silly coding standard?
On 9 d=E9c, 21:25, Leigh Johnston <le...@i42.co.uk> wrote:
On 09/12/2010 19:33, Leigh Johnston wrote:
On 09/12/2010 19:19, Leigh Johnston wrote:
On 09/12/2010 14:04, Michael Doubez wrote:
On 9 d c, 14:13, Leigh Johnston<le...@i42.co.uk> wrote:
On 09/12/2010 12:18, Michael Doubez wrote:
On 9 d c, 02:32, Leigh Johnston<le...@i42.co.uk> wrote:
On 08/12/2010 21:34, red floyd wrote:
On Dec 8, 12:42 pm, Leigh Johnston<le...@i42.co.uk> wrote:
On 08/12/2010 20:19, Keith H Duggar wrote:
On Dec 8, 12:05 pm, Leigh Johnston<le...@i42.co.uk> wrote:
On 08/12/2010 16:59, Yannick Tremblay wrote:
So for example, although I do not beleive that there exists a
number
of lines per functions that is the threshold between a bad an=
d
a good
function, in some evironment, it can be worthwhile to place a
rule
that say that all "all functions must be less than XX lines
unless a
good explanation is provided".
Why provide a good explanation? Functions that contain switch
statements are often long and require no explanation. The
following
function of mine is over 100 lines long and requires no
explanation:
[snip unbelievably naive and primitive mess]
Wow ... just wow ... that is a prime(evil) example of the horri=
fic
code that poorly trained fanboys write when they lose all (or
never
had any) rational perspective on code readability.
It's exactly the kind of stuff you see all over Micros$$t code =
so
I guess it's not so surprising in your specific case; but ... w=
ow.
You are right about one thing though, no explanation should be
provided in this case. Instead the code should be instantaneous=
ly
rejected and the programmer sent to rehab.
There is nothing wrong with the constructor I posted. It
contains no
branches (is therefore very simple) and all it does is construct
objects
which is generally what constructors do. It is also perfectly
readable.
and it would be much clearer if it was table driven. All that nas=
ty
inline stuff could be replaced by a loop and a table.
Just to show that I am not immune to constructive criticsm (and to
shut
the trolls up) I decided to rewrite the constructor so it uses a
table
and luckily the use of templates made sure it wasn't too tedious:
[snip]
Actually, I'd rather have a builder pattern:
[snip]
ByteCodeRepository repository = ByteCodeRepository::Builder()
.addNamespace(L"")
.addNamespace(L"system"),
.addNormalFunction<wait_1>( L"wait" )
.addNormalFunction<wait_2>( L"wait" )
[snip]
.addNamespace(L"text"),
.addNormalFunction<tokens> ( L"tokens" )
.addNormalFunction<to_utf8> ( L"to_utf8" )
.addNormalFunction<from_utf8> ( L"from_utf8" )
.addNamespace(L"math"),
// ...
;
};
Hereafter it is not too hard to make a loop for registration.
But I agree that if it doesn't make sense to keep it afterward, you
could put that in a function and it can exceed the XX lines limit.
I don't see how this is any better than the other two solutions.
I see the following advantages:
- the namespace string is not repeated, typing errors are reduced.
- the namespace.function tree becomes apparent which make reading
easier (you could also reorganize it into subinitialisation functions=
/
modules). In fact, syntactic sugar could be designed to make easier t=
o
read.
- the init can be put into its own file, which separates the code
and the initialisation data.
- the structure can be reused/preprocessed/enhanced before
insertion: gives a base for future changes (in particular using more
than one insertion sequence).
--
As I value code readability quite highly I have decided to go with you=
r
solution Michael and it turned out that using the pattern made things =
a
lot cleaner.
And to preempt the vociferous Duggar yes it is obvious that using desig=
n
patterns generally do make things cleaner but I have to admit I have no=
t
*knowingly* used this particular pattern before. I am not ignorant of
design patterns in general; I use the observer pattern a lot for
example. :)
Actually whilst this builder pattern (which does not appear to be the
same as the builder pattern in GoF) solution does kind of look clean it
does smell of over engineering the simple problem of allocating a
collection of objects.
True, it does seem a lot of effort for no real technical gain. But
IMHO, this is a one time effort for the whole lifetime of the project
(let say two years :) ) which may justify it in terms of ROI.
As for the pattern, IIRC the exact name is is "named parameter idiom"
but since it effectively constructs the data, I guess it becomes a
builder pattern.
The only real problem with my initial solution of a simple list of
explic object allocations in a constructor is the repetition of code and
string literals; is this such a big deal? I think not. Ian pointed out
that this would be fine if the code was generated.
The intermediate table based solution probably sucked the most.
Perhaps the solution would not be to build a central data but using
the same pattern for directly calling the relevant functions.
In particular, you wouldn't have all this storage of functions of
different type. All the most since it is certainly already done
somewhere else (I guess).
Something along the line:
const std::wstring iCurentNamespace;
builder& add_namespace(const std::wstring& aNamespace)
{
if( /* namespace does not already exists */ )
{
add_namespace(scope::Namespace, aNamespace);
}
iCurentNamespace = aNamespace;
}
template <typename T>
builder& add_normal_function(const std::wstring& aFunction)
assert( !iCurrentNamespace.empty() );
specific_namespace(iCurrentNamespace).symbol_table()
.insert(aFucntion
, value(FunctionDefinition,
function_ptr(new T())));
return *this;
}
And then you put your build tree in a function.
--
Michael