[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] Coding Styles - Indentation / Tabs / Spaces
From: |
Joseph Heled |
Subject: |
Re: [Bug-gnubg] Coding Styles - Indentation / Tabs / Spaces |
Date: |
Sat, 27 Oct 2012 13:37:12 +1300 |
Hi,
I am in favour of
-- uniform style in a project
-- not mixing tabs and spaces. I would say use spaces only.
-- reasonably cramming as much code into HxW as possible : my
eyesight forces me to relatively large font, even on a large screen.
So I *hate* lines with a single curly (wasting the most precious
resource, vertical lines). I also prefer 2 spaces indentation - could
probably live with 4.
-Joseph
On 27 October 2012 13:01, Michael Petch <address@hidden> wrote:
> On 2012-10-26 16:54, Russ Allbery wrote:
>> Of course, any IDE or tags system will let you do this more easily and
>> without regard for formatting, but when I'm hacking on code or
>> investigating some problem, I frequently find that poking about with a
>> pager, grep, and a UNIX shell is faster than diving into an IDE, so these
>> sorts of neat tricks can be quite helpful.
>
> I appreciate the feedback, and I think (and it is a personal opinion)
> that I'd probably stick to a more standardized format for C functions,
> although others opinions on the matter would be welcome. As you point
> out a tags system works well for this (and I use this procedure quite
> often when I'm working from a command line).
>
> Just in case anyone reading hasn't used a tags system, it is a utility
> that usually parses any of the common languages and dumps all the
> identifiers and their context to a file/stdout so that one can easily
> search for occurrences more easily with utilities like grep. Many of the
> text editors (including vim,vi,emacs etc) can actually use a ctags
> generated file.
>
> It might be easier to find functions using grep directly (and formatting
> the source a certain way as you suggest) but finding global variable
> definitions can be more problematic.
>
> Generally what I do is use ctags (it handles a lot of languages, not
> just C) to process a directory, dump the tags to the file once and from
> then on I simply grep the tags file rather than rescan a directory. In
> the case of gnubg running ctags and outputting to a file allows me to do
> this:
>
> ctags -R -x >tagfile
>
> and then when needed:
>
> grep -w ^main tagfile
>
> main function 41 makeweights.c extern int main( int
> argc, /*lint -e{818}*/char *argv[] )
> main function 53 bearoffdump.c main( int argc, char
> **argv ) {
> main function 67 mec.c int main (int argc,
> char **argv)
> main function 183 lib/mt19937ar.c int main(void)
> main function 536 config.guess main()
> main function 546 simpleboard.c main(int argc, char
> *argv[])
> main function 598 makehyper.c main ( int argc, char
> **argv ) {
> main function 682 config.guess main ()
> main function 1293 makebearoff.c extern int main( int
> argc, char **argv )
> main function 1342 config.guess main ()
> main function 1763 non-src/sgf_y.c int main( int argc,
> char *argv[] ) {
> main function 1855 sgf_y.c int main( int argc,
> char *argv[] ) {
> main function 1864 external_y.c main( int argc, char
> *argv[] ) {
> main function 1864 non-src/external_y.c main( int argc,
> char *argv[] ) {
> main function 4743 gnubg.c int main(int argc,
> char *argv[])
>
> I find ctags convenient. The output above was from the cross reference
> output which includes global variables, macros, functions etc.
>
> --
> Michael Petch
> CApp::Sysware Consulting Ltd.
> OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304
>
>
>
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-gnubg