Spatiophobia?

[ultifinitus]

andywestken wrote:

which is why I stated that I strictly follow the one variable definition per line rule; and I always initialize them.

That's painful...

Gosh, if you were to look through my source code, you'd hardly see a variable lonely enough to be declared on it's own line, unless of course the program is trivial...

Unless you're doing something tricky like using a struct with all your variables declared beforehand or just using arrays or vectors or something =]

struct allTheVariables{
int a,b,c,d,e,f,g,h,i,j,k,l,m,youGetThePoint; //would you really take ~14ish lines for this?
};

allTheVariables yayIOnlyHaveToUseOneLine; //!! 

[coder777]

would you really take ~14ish lines for this?

Yes and no. Having such an amount of variables looks very much like a design flaw.

Usualy when a function becomes too large (> one page) i break them into smaller pieces.

[ultifinitus]

Yes and no. Having such an amount of variables looks very much like a design flaw.

Consider this:

I'm writing a program that keeps track of the following information
job number
date created
10 fields specific to the job, as integers (status at any particular time)
customer name
customer number (s)
customer address (s)
customer email (s)
warranty company's name
warranty company's number (s)
warranty company's address (s)
number of times communicated with both on any medium
description of problem
and long term notes on this particular job
communication password



ALL of this information is relevant to a single object.
While all of the variables are not going to be on a single line, I would prefer the concise readability of maybe 5-6 lines vs the 22 lines necessary to splay it out in a single variable to single line principal.

[andywestken]

struct allTheVariables{
int a,b,c,d,e,f,g,h,i,j,k,l,m,youGetThePoint; //would you really take ~14ish lines for this?
};

Yes, I would generally use however many lines it takes.

The example you give is hopefully not a typical example of you code! ;-)

I generally like to use more descriptive names for code, and current convention appears to be to avoid abbreviations. Do you use short variable names yourself?

(Another strict rule: no abbreviations. In this case, exceptions are made, but only for variable names which are widely used and clear in context).

ALL of this information is relevant to a single object.

When I read you list I see a Customer and Warranty class, as well as a Job (which I take your class to be?)

I would give the Job class associations to the corresponding Customer and Warranty objects, rather than have it contain their information.

I would prefer the concise readability of maybe 5-6 lines vs the 22 lines necessary ....

Another difference! I know plenty of people who agree with you, but I find the decadently spaced version easier to read.

[1vRz3TCk]

I have never been overly bothered by the number of lines needed/taken for variable definition.
I do try to follow the one variable definition per line rule. If they are part of a class then they may well have comments along with them to document the class and if not they are consistent with other declarations in the class.

If they are in a function they are as close to where they are used to not overly require more that one per line to reduce space.

I also find a more spacious code layout easier to read. There are only a few exception to the one expression per line 'rule' that I break.

[ultifinitus]

The example you give is hopefully not a typical example of you code! ;-)

Of course not =]

However it was pointing to a difference in out preference for sure, I dislike having my variables so spaced out, because it seems unnecessary, and I'm "lazy" (I'm really not, but in this instance it's the best fitting word)

I generally like to use more descriptive names for code, and current convention appears to be to avoid abbreviations. Do you use short variable names yourself?

Oh come on, now you're just busting my chops =]
No one I know would actually use "a" as a variable that they intend to use for something useful!

(Another strict rule: no abbreviations. In this case, exceptions are made, but only for variable names which are clear in context).

I use abbreviations in variable names if I deem it necessary in the situation. There are times when I'll be using a variable tons of times, and I don't want to sit there typing customerName, where I could be typing cmName.

When I read you list I see a Customer and Warranty class, as well as a Job (which I take your class to be?)

You could certainly separate the classes. I would, in fact, prefer to have a separate warranty class. However in this instance there are other things preventing me from ripping them apart (using someone else's file system, as well as some other situation specific issues) and yes, I would, in my personal programming keep things spaced out more, however this is an example (however poor)

Another difference! I know plenty of people who agree with you, but I find the decadently spaced version easier to read!

And there's the issue, it's just not readable to me. I can navigate my code more quickly, and create code more efficiently if it's grouped closer. I can read the information faster and I don't have to take the time to extract the necessary information if it's concise. (but that's just me)

[Duthomhas]

I tend to stick to the one-per-line rule too, except when just a short list of ints or the like.

Consider this:

[gadzillion variables]

Those all go into a struct or class, which is taken by itself anyway, so having some 14 variables displayed nicely doesn't impact readability.

struct customer_info_t
  {
  unsigned           job_number;
  date_t             date_created;
  unsigned           bit_fields;
  string             customer_name;
  vector <string>    customer_numbers;
  vector <address_t> customer_addresses;
  vector <string>    customer_emails;
  string             warranty_company_name;
  vector <string>    warranty_company_numbers;
  vector <address_t> warranty_company_addresses;
  unsigned long      total_communications_with_customer_or_warranteer;
  string             description_of_problem;
  string             long_term_notes;
  password_t         password;
  };

Then, when you need all that information, just declare a variable for it:

customer_info_t ask_for_customer_info()
  {
  customer_info_t ci;

  cout << "job number: ";
  cin >> ci.job_number;

  cout << ...
  }

[1vRz3TCk]

Out of interest, was anyone else taught to read declarations backwards?

i.e.
int * x; as x is a pointer to an int.
char * const y; y is a constant pointer to a char.
char const * const z; z is a constant pointer to a constant char.

[ultifinitus]

Consider this:

[gadzillion variables]

Hahaha, I laughed at this.

I agree duoas, and in truth, with such variables I would indeed separate them into different lines (especially with your super long variable names)

There are times when it's just quicker to stick with one, though in most of these cases it's just better to go with an array or something similar.

I will hold to my paradigm that I prefer (this word is really quite ironic:) conciseness (really feels like it should be concisity or something like that...) to empty space. This is the reason I attach my opening curly braces (even if I have a space after the beginning of the statement at times) it all depends on the situation, and I don't think that there is typically any one method of anything that is always the best in every situation.

[andywestken]

@ultifititus

Oh come on, now you're just busting my chops =]

This it not an expression I've come across before. But I should prob. have used another smiley here.

I did wonder what that many "normal" length variables would look like. Of course, it would probably break the "80 column rule". Duoas' variable names certainly would!

As people have different preferences, and even find some styles of lyout harder to read, maybe it should something that is mentioned in job adverts and resumes/cvs? "Agile, compact-ist software house seek developer with C++, TDD, and GSOH" ???

[Duthomhas]

LOL, I would probably break that up a little also -- I tend to like to keep my variable names under 20-25 characters max...

[andywestken]

:-) Your longest variable even beat the longest single identifiers (as in, no namespace/class/... qualifiers) I've ever come across (#3) and is almost as long as the one I found after a quick google:

#1 ConvertSecurityDescriptorToStringSecurityDescriptor
#2 total_communications_with_customer_or_warranteer
#3 CoMarshalInterThreadInterfaceInStream

(OK, they're functions, but...)

[tition]

Haha here is some flame material for you:

Whenever declaring function arguments I put them always on a single line. Rationale: function arguments are supposed to be a detail you should very very rarely be looking at: the name of the function should make it self-explanatory what should the arguments be. Instead of breaking lines, I try to rename my functions.

[Edit:] of course, this rule has an important exception: if I am working on the function at the moment, it gets broken in many lines so that I can quickly add more arguments/change the old ones.

[andywestken]

On the subect of function arguments, do you think the following toy class's style is valid?

class Date
{
public:
    Date();
    Date(int, int, int);
    Date(const Date&);

    void SetDate(int, int, int);

    int GetYear() const;
    int GetMonth() const;
    int GetDay() const;

    ...

};

[Duthomhas]

I prefer description over shortness, even if the variable names get a little longer. It just means a few more bytes of source code, but then you don't have to be wondering too much what 'x' means when it isn't just some local foo variable iterating through a 3-line loop.

[tition]

@andywestken

    Date(int, int, int);

    void SetDate(int, int, int);

This is very much against my conventions: variables should always be named!
Compare
void SetDate(int, int, int);
to
void SetDate(int Day, int Month, int Year);
or to
void SetDate(int Month, int Day, int Year);
if you are US inclined! The second and the third functions are self explanatory. The first is incredibly ambiguous and calls for a mistake, especially in an international team.

[Duthomhas]

Agreed. The only time variables should not be named is when they are dummies.

[helios]

The first is incredibly ambiguous and calls for a mistake, especially in an international team.

They're both substandard, anyway. The proper way to pass date parameters is in big endian.

[andywestken]

The "Date" sample I quoted is from a C++ text book I browsed in passing the other day, and really threw me. I think that books aimed at beginners should use exemplary coding style (whatever choice they make of the details like bracketing/spacing/indenting). Omitting the parameters is one of the most evil things to do.

I don't recall the author, but I do know it was the book with the most copies, which generally means that it is a set text.

[Duthomhas]

[quote helios]They're both substandard, anyway. The proper way to pass date parameters is in big endian.[/quote]I agree, but most people seem to ignore the obvious logic of it, and stick with their backwards and twisted conventions, like that obnoxious M/D/Y thing we've got going here in the USA.

....unless you mean that the actual values themselves should be big endian....