Re: Update info.c to use size_trun_len() & Co.

[Pavel Roskin <proski gnu org>]

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