bugfindutils - Bugs: bug #14615, Coding rules

 
 

bug #14615: Coding rules

Submitter:  pol tuiu <poltuiu>
Submitted:  Thu 22 Sep 2005 11:16:45 AM UTC
   
 
Category:  None Severity:  2 - Minor
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  jay
Originator Name:  stephane despret Open/Closed:  Closed
Release:  4.2.25 Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 08 Oct 2005 06:17:35 AM UTC, comment #5: 

As per the earlier comments, I'm not about the change the current practice unless the GNU coding standards change in this area.   I note however, that using only spaces would still conform to the GNU coding standard, I think.

James Youngman <jay>
Group administrator
Tue 04 Oct 2005 02:57:04 PM UTC, comment #4: 


> Maybe I should change my .emacs configuration to add "untabify" to write-file-hooks.


I wouldn't.  The find code right now matches the defacto standard of mod8 tabs.  This is the same as other GNU projects and is the default for emacs, vi, vim, etc.  All is good.  So unless you are in conflict with other developers and cannot come to a resolution I would suggest to let things as they are.

Additionally if that hook were added it would create a huge change delta on the first commit of the file and that would be best avoided because the changes would not be real code changes.  You would need a special indent(1) configuration.  File sizes would increase.  This special config if yours would bleed over into other projects.  It is generally a mess.

Bob Proulx <rwp>
Group Member
Mon 03 Oct 2005 11:07:51 PM UTC, comment #3: 

Maybe I should change my .emacs configuration to add "untabify" to write-file-hooks.

James Youngman <jay>
Group administrator
Fri 23 Sep 2005 03:39:11 AM UTC, comment #2: 


> findutils is consistent in that \t is always treated as 8 columns
> If your editor cannot properly be configured to treat tab characters as eight columns, then I would argue it is a bug in your editor


Agreed.  The standards only say that horizontal tab moves the print head to the next tab stop.  But the defacto standard is that this is on the next mod-8 column.  All of emacs, vi, mozilla, indent, etc. all expect tabs to align with mod-8 by default.

Bob Proulx <rwp>
Group Member
Fri 23 Sep 2005 12:34:36 AM UTC, comment #1: 

The GNU Coding Standards, http://www.gnu.org/prep/standards/standards.html#Formatting,  specify how many columns in each open brace must appear (2 column indent for every indentation, and braces are indented on the next line, leading to the typical 4 column increase between levels of braces).  Beyond that, it is silent whether a program must use spaces or tab characters, as long as it is consistent.  findutils is consistent in that \t is always treated as 8 columns, in part inspired by the GNU emacs c-code-mode, as well as GNU indent, which both clean up whitespace (on save, 8 consecutive leading spaces are turned into a tab) in this manner to reduce the size of files. If your editor cannot properly be configured to treat tab characters as eight columns, then I would argue it is a bug in your editor, and not in findutils.

Eric Blake <ericb>
Group administrator
Thu 22 Sep 2005 11:16:45 AM UTC, original submission:  

In the code, we find a mixture of tabulation and space, generally in the form :
- first brace on column zéro
- second brace with one tabulation
- third brace with tabulation and four spaces
- fourth brace with two tabulations
..etc

It's not a good idea because on some éditor the code is not indented at all.

pol tuiu <poltuiu>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 5 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-10-08 jay Assigned toNone jay
    Open/ClosedOpen Closed
2005-10-08 jay Severity3 - Normal 2 - Minor
    StatusNone Invalid
2005-09-22 poltuiu Carbon-Copy- Added -email is unavailable-

Back to the top

Powered by Savane 3.13-3230.
Corresponding source code