Update info.c to use size_trun_len() & Co.
Pavel Roskin
proski at gnu.org
Fri Aug 31 14:42:08 UTC 2001
Hi, Timur!
> > Don't comment the code you are replacing and the bugs you are fixing -
> > e.g. "1000 should do 1K, not 0K."
>
> I was writing new patch this evening, and asked myself - what commenting
> policy we should use.
I prefer to have comments for functions - what they do, what arguments
they take and how they should be used. Whenever you use a function,
consult its comment - the internal implementation is more likely to change
than the semantic of the function.
Comments for the code inside functions should be used with care - they
often describe details that should already be clear from the code.
Changing the code can make comments irrelevant and confusing.
> For ex. at my work in average we comment every 4 lines of code, so, very
> detailed commenting. MC, in turn, practically not commented. I think, we
> should agree on amount of comments for future patches.
Commenting every 4 lines is probably too much. But I don't know what
comments you mean. There are two types of comment - useful and useless.
These are useless comments:
if (size = 0) /* Do it only is size is 0 */
len = 5; /* or it won't work */
This is a useful comment:
/* Warning, recalc may be a macro */
x++;
recalc(x);
I prefer to use only comments that give information beyound the code.
This doesn't apply to functions - their comments are very important even
if the function is trivial.
> > Don't use "unsigned" - use "unsigned int". I remember seeing a warning in
> > some compiler about it.
>
> I think, as we started once that movement into the glib direction, we should
> continue with it. I've started to rewrite some small independent arts of MC
> to use glib data types, functions, etc. I think, we should try to use as much
> from this library, as possible. It'll make MC smaller, mor portable, less
> buggy(I hope:).
I don't object against use of gint and guint, but don't expect too much
from glib. My experience shows that glib-1.2.10 is less portable than mc
itself. The 1.3.x series depend on pkgconfig, which is badly designed -
it must be present on the compiling system, unlike e.g. libtool, which is
distributed in the tarball.
> So, I'd like your confirmation, that we are prefer constructions like:
>
> "gint" in opposit to "unsigned int"
I think you mean "guint".
> and so on. At the moment we have very dangerous mix, so it's better to eliminate
> it as much as possible.
The really dangerous mix is malloc vs. g_malloc and free vs. g_free. To
fix the problem, g_malloc and g_free should be used in the editor, and
this would mean that we can forget the idea of further synchronization
with Cooledit, except maybe the syntax engine.
--
Regards,
Pavel Roskin
More information about the mc-devel
mailing list