This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: more missing gplv3 notices


   > >    2009-01-12  Christopher Faylor  <me+cygwin@cgf.cx>
   > > 
   > > 	   * amd64-windows-nat.c Rename gdb-specific win32_* to windows_*
   > > 	   throughout.
   > > 	   * i386-cygwin-tdep.c: Ditto.
   > > 	   * i386-windows-nat.c: Ditto.
   > > 	   * windows-nat.h: Ditto.
   > > 	   * windows-tdep.c: Ditto.
   > > 	   * windows-tdep.h: Ditto.
   > > 	   * windows-nat.c: Ditto.
   > > 
   > > See the node "Style of Change Logs" in standards.info for details.
   > 
   > It does not say that explicitly (doesn't mention multi-file changes at
   > all), and this is not the prevailing style used by GDB developers
   > based on my survey of the changelogs.

   Sorry, I forgot I shouldn't talk about these things.

Though, to open a can of worms,

|    It's important to name the changed function or variable in full.
| Don't abbreviate function or variable names, and don't combine them.
| Subsequent maintainers will often search for a function name to find all
| the change log entries that pertain to it; if you abbreviate the name,
| they won't find it when they search.
| 
|    For example, some people are tempted to abbreviate groups of function
| names by writing `* register.el ({insert,jump-to}-register)'; this is
| not a good idea, since searching for `jump-to-register' or
| `insert-register' would not find that entry.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]