Quote:

What's next on the discussion list? Vi or Emacs? Code formatting style? OS distribution?

Yeah, while we're at it, anybody using K&R style bracketing needs to be taken out into the parking lot and shot. Harsh, but fair!

Quote:
Yeah, while we're at it, anybody using K&R style bracketing needs to be taken out into the parking lot and shot. Harsh, but fair!

Quote:

Yeah, while we're at it, anybody using K&R style bracketing needs to be taken out into the parking lot and shot. Harsh, but fair!

Quote:
I have been forced to use K&R style for the last two days

  if (x) {
    doSomething()
  }

  if (x)
    {
    doSomething();
    }

  if (x)
  {
    doSomething();
  }

Quote:
I've never really understood why some people get majorly obsessive about commenting code - I don't know how many times I've heard "code without comments is bad".

Generally speaking, your code should speak for itself, if it isn't then there's something wrong somewhere! I know that in practice this isn't always possible, but when I come across a situation like this, a single line comment usually suffices.

Like above, giving variables and functions proper descriptive names is about the biggest favour you can give yourself and others who access the code.

Bad code is bad code, no amount of commenting is going to fix it!

Quote:
It is all a balance. You need a concise function name and a concise set of comments. Just because the compiler gives you the ability to have a 255 char long function name doesn't mean you should have an insanely long function which describes exactly what it does. You shouldn't put a comment in for every single line either.

   Allman/BSD     Horstmann      GNU           Whitesmiths     K&R

   if (b)         if (b)         if (b)        if (b)          if (b) {
   {              {  x = 1;        {              {               x = 1;
      x = 1;         y = 2;          x = 1;       x = 1;          y = 2;
      y = 2;      }                  y = 2;       y = 2;       }
   }                               }              }

Quote:
I hate K&R Bracketing

if (x > y) then

begin

    statement1;

    statement2;

end;

if (x > y) then begin

    statement1;

    statement2;

end;

Quote:
Personally, I use K&R, though I disagree with Jeff's theory about how/why it evolved.

Quote:

So I'm assuming that when coding in Delphi, you use:
. . .

Quote:
Personally, I set my tabstops to 2 spaces and indent once for each K&R indentation.

Quote:
Are there any members of this BBS that are NOT programmers?

Quote:
tabstop should never be set to anything other than 8. You really should be using what vim calls 'softtabstop' (along with 'shiftwidth'), which allows you to edit as though a tabstop is 2 spaces, but leaves the tabstop definition at the standard 8 spaces.

Quote:
tabstop should never be set to anything other than 8.

GNU/Emacs freak.

Quote:
You really should be using what vim calls 'softtabstop' (along with 'shiftwidth'), which allows you to edit as though a tabstop is 2 spaces, but leaves the tabstop definition at the standard 8 spaces.

Quote:
I really hope you also have 'expandtab' set (which, for the non-vim users, turns tab stops to spaces).

Quote:

Quote:
tabstop should never be set to anything other than 8. You really should be using what vim calls 'softtabstop' (along with 'shiftwidth'), which allows you to edit as though a tabstop is 2 spaces, but leaves the tabstop definition at the standard 8 spaces.

I'm trying understand what you're saying here, but I don't get it (not a vim user if that matters).

I used the names of vim settings, since I believe Bitt mentioned using vi in another post, and it's the terminology I'm most familiar with.

A 'softtabstop' set to two spaces means that when you hit tab in the editor, rather than inserting a tab character, "\t", it will insert two spaces. Once you tab over a full tab stop, it replaces spaces with a tab character. This last behaviour is actually quite odious.

Fortunately, vim also has a setting called 'expandtab', which changes all literal tab characters into the equivalent number of spaces (depending, of course, on what your tabstop is).

Shiftwidth is a setting that allows you to shift lines of text (in- or outdent) by a certain number of spaces.

In vim, I never actually use the tab key. I use a shift operation to do all my non-automatic indenting.

Quote:
Why would you want your tabs set to 8?

Using your favourite language, do the equivalent of the following:
Code:

---

perl -e'print "\n\t#\n        #\n";'

---

There are 8 spaces in that last part. Run that wherever you choose and let me know how often those hash marks don't line up (assuming a fixed width font, of course). Next, create a simple text file containing those two lines. Print it out on paper, again with a fixed width font. I bet the colons line up, right? Then, in a shell, cat the file (I think the old DOS command was 'type'). How big are the tabs? Throw some <pre></pre> tags around it, and view it in a webpage. I bet those hash marks line up, right? They do in Firefox, links, lynx, and konqueror.

Aside from a text-editor where someone has manually changed the tabstop to something other than 8, a tabstop is 8 spaces. If you look at the documentation of the text-editor that person is using, I'd be willing to bet that the default tabstop (which they've changed) is 8.

Where else, other than your text editor, can you change how a tabstop is displayed? I'd bet nowhere. That's because 8 spaces is the standard. Don't change what's standard.

Quote:
I usually indent everything 2 spaces and have my editor set to insert spaces instead of tabs.

This sounds like it's the equivalent of having 'expandtabs' turned on in vim.

Quote:
Of course, with the editors I use (VS.net and Delphi) the whole tab functionality is really obsolete anyway. VS.net formats your code as soon as you put your closing brace and Delphi has a "smart tab" which inserts spaces up until you reach the next character-after-a-space on the previous line (or the most recent line that extends as far as you're typing).

Yes, smartindent is great -- vim has that, as well, and I use it. It doesn't make tab functionality obsolete, however, as, if there are literal tab characters in your file when it gets saved, then they're still there regardless of how your editor displays them.

Quote:
However, on this subject, tabs in general just drive me nuts. In fact, if the editor doesn't have the option to insert spaces instead of tabs, I just ignore the tab button. I hate opening code in a different editor and having it look like garbage because the previous program used a different tab setting than the one I have now.

Now you know why you should never change the tabstop setting from 8. If you have, the only place your formatting will ever look "correct" is in the place it was originally edited.

Quote:
And on THAT subject, why is it that no one seems to ever format SQL code?

We do -- it's a department coding standard.

Quote:
Aside from a text-editor where someone has manually changed the tabstop to something other than 8, a tabstop is 8 spaces.

Quote:

Quote:
tabstop should never be set to anything other than 8.

GNU/Emacs freak.

Au contraire. The first thing I do after installing a linux distro is remove Emacs. (Historically, it was because I never used it, and when using tiny hard-drives, it took up waaaay too much space for something I never used. Now it's just a matter of principle.)

Don't mistake my advocacy of 8 space tab stops as advocacy of GNUs standard for mixing tabs and spaces. That's even worse than using non-standard tabstops, since the tabs are at least internally consistent.

Quote:

Quote:
You really should be using what vim calls 'softtabstop' (along with 'shiftwidth'), which allows you to edit as though a tabstop is 2 spaces, but leaves the tabstop definition at the standard 8 spaces.

Nope, just "tabstop=2 shiftwidth=2". Interesting idea, though.

  if (!statOnly) {

    if (result.errorCode) {

      if (result.messages.size() > 0) {

        TXT_Printf(stderr, SEV_ERROR, "%s\n", (const char *)result.messages[0]);

      }

      else

        TXT_Printf(stderr, SEV_ERROR, "Unknown error.\n");

    exit(result.errorCode);

  }

        if (!statOnly) {

                 if (result.errorCode) {

                        if (result.messages.size() > 0) {

                                TXT_Printf(stderr, SEV_ERROR, "%s\n", (const cha

r *)result.messages[0]);

                        }

                        else

                                TXT_Printf(stderr, SEV_ERROR, "Unknown error.\n"

);

                exit(result.errorCode);

        }

Quote:

Quote:
I really hope you also have 'expandtab' set (which, for the non-vim users, turns tab stops to spaces).

Nope.

See, I find it useful for indents to be one character. It helps me find matching indents better when they span a screen's worth of data.

if ( a<b ) {
  if ( c<d ) {
    if ( e<f ||
         g<h ) {
      doit();
    }
  }
}

if ( a<b ) {
ttif ( c<d ) {
ttttif ( e<f ||
ttttsssssg<h ) {
ttttttdoit();
tttt}
tt}
}

Quote:

Quote:
Aside from a text-editor where someone has manually changed the tabstop to something other than 8, a tabstop is 8 spaces.

Not true in my world, I'm afraid. VS.NET has it set to 4

Huh. I haven't used windows since... uh... NT 4.0, I think, so I'm coming to this primarily from a unix standpoint. I'm certainly not up on all the fancy IDE editors out there, particularly on Windows.

Quote:
I also just realized that vs.net indents four rather than two.

Well, at least it's a good indent. 2 space indents are too small, IMHO. I like 4 space indents.

Quote:
Anyway, I guess in my early days I ran into too many apps where tabs were not 8 spaces that I just gave up on tabs altogether.

I used to like tabs. Then I started working with other people.

Tabs just shouldn't be used for formatting code.

    ...
      else
        TXT_Printf(stderr, SEV_ERROR, "Unknown error.\n");
    exit(result.errorCode);

Quote:
... never touched a piece of code in their lives.