nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] Should we rename and untypedef nano's structs?


From: Brand Huntsman
Subject: Re: [Nano-devel] Should we rename and untypedef nano's structs?
Date: Sun, 19 Aug 2018 16:50:18 -0600

On Sun, 19 Aug 2018 10:30:06 -0400
Devin Hussey <address@hidden> wrote:

> Do you have any thoughts about this?

About time.

Getting rid of typedef's clutters the code but I also don't agree with the 
current naming scheme that doesn't indicate if the typedef is a struct, enum or 
union. Some names have "struct" in them, others don't. None of the enums have 
"enum" in their name, they all end with "_type" (except for file_format) but 
many structs also end with "type". What about prefixing each typedef with s_ 
for struct, e_ for enum and u_ for union?

Renaming openfilestruct to buffer or s_buffer makes sense for this example.

        winio.c: int buffer_number(s_buffer *buffer)

There are also these functions that should probably be renamed as well. Perhaps 
change both opennode and fileptr to buffer. And do the same for all other 
functions when renaming typedef's they use.

        proto.h: openfilestruct *make_new_opennode(void);
        proto.h: void unlink_opennode(openfilestruct *fileptr);
        proto.h: void delete_opennode(openfilestruct *fileptr);

Is filestruct used for anything not a line? Renaming to line would be best if 
that is all it is. Node is a good name for an element in a generic list, but 
not if the list is always a buffer of lines.

A shortcut(sc) is a key bind right? Bind is used in nanorc to create them, why 
not rename to keybind. Multiple names for the same thing causes confusion.

Renaming syntaxtype to just syntax would be good, no reason to add some 
illogical suffix to the end (not all syntaxes are languages...). And colortype 
should be prefixed with "syntax_", syntax_rule or syntax_color (the color 
command creates them). Child structs should inherit their parent's name as a 
prefix, so if syntaxtype becomes file_syntax then colortype should become 
file_syntax_color.

And when renaming, maybe try not to fall into the same trap we are in now, and 
don't shorten names to something meaningless. Most programmers know pos is 
position but hist might be histogram or history. A buffer is used everywhere in 
nano and can be short, but less used structs should have meaningful names. 
Renaming poshiststruct to file_position_history or file_pos_history indicates 
what it does, and variables/parameters for it could be something short like 
"history".

Perhaps briefly discuss each renaming and what the struct is used for before 
submitting a patch.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]