Re: [Bug-gnubg] Coding Styles - Indentation / Tabs / Spaces

[Joseph Heled]

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