Rick Altherr wrote:
>
> New developers to the project.  Not all advanced coders _prefer_
> shorter names just to save on typing.  I'm not suggesting we
> "dumb-down" anything.  Using cryptic short names to save on typing is
> an elitist attitude that makes the barrier to entry for new developers
> higher and makes the time to come up to speed on a portion of the
> codebase longer.  Code should be clear and concise.  If a longer
> function name describes the effect of the function better, then it
> should be the longer name.  That doesn't mean that every function
> should have a long name.  Same for types.  If a longer or additional
> type name would clarify the code, then it should be used.  u32 doesn't
> clarify anything.  It just replaces the familiar type defined by a
> well-known standard with something 5 characters shorter.
Ack from me. If I see uint32_t, I know immediately what it is, and that
it comes from a system header and has a well-defined meaning.

Wrappig that in a project header to provide u32 means I have to look up
where it is defined.


> I could say the same of everyone else.  Considering the entire issue
> is rooted in preference, there are no hard facts to be presented.
>  Some prefer to have shorter names, some prefer to have more
> descriptive names.  Either option is workable, but in my experience
> with introducing developers to projects, more descriptive names and
> types lower the barrier to entry and reduce the amount of guidance the
> current developers need to provide.
IMHO, it's not so much length - I prefer short names as long as they are
descriptive, but if there is a defined standard, I prefer to use that
(the the Linux way is "uint32_t" - there is more code for userspace,
which uses that, than there is kernel code, and more programmers will be
familiar with the userspace definitions, which also match C99 and are
not Linux-specific).

cu
Michael

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to