views:

123

answers:

4

Is there a way to do this:

valueType x = 1, y = 1, z = 1;

with less characters?
e.g. When I have a large amount of state to initialize to the same starting value.
Thanks!

+5  A: 

You could try

int x, y, z;
x = y = z = 1;

But I can't see how it would help you... if you have really lots of variables you must initialize to the same thing, you could consider using some kind of collection:

var myInts = new List<int>();
for (int i = 0; i < 1000; i++)
    myInts.Add(1);
Bruno Reis
I was trying to avoid the whole typing x twice, if I could!
Byron Ross
Call it `b` then... :p
Bruno Reis
That's 27 characters - 3 more than he originally had, plus I'm sure the some of the variables have much longer names than those examples.
Mark Byers
But I need it to b x :)
Byron Ross
It's a readability thing more than anything else, there is a lot of state.
Byron Ross
Without implicit variable declaration, you're either going to need to type them twice (once for declaration, once for assignment) or in the manner you first posted. The only alternative would be something like: " int x = y = z = 1; " which isn't valid.
Marc Bollinger
@Bruno, the issue for my application is that the variables all need names, are logically grouped, but of different types (all in the same group are the same type). I can't access them by State.myVals[i].
Byron Ross
@Byron: if they are fields of an object, you could use reflection to initialize all of them in a loop, and still be able to access them by name.
Bruno Reis
@Byron: or you could define constants and access your state through them: `State.myVals[pression_top]`
Bruno Reis
+1  A: 

If the starting value is zero and they are members of your class (not local variables) then you don't need to explicitly initialize them to zero.

Otherwise, no.

Would it make sense to use arrays instead of having a large number of parameters?

Mark Byers
That's what I thought, and no, they're not 0.
Byron Ross
A: 

in general I think it tends to be better to separate each declaration. It tends to make it easier to change around later.

especially when lots of variables tend to suggest that they should be combined into another object.

so I'd tend to do...

valueType  x = IntialValue;
valueType  y = IntialValue;
valueType  z = IntialValue;

etc...

Keith Nicholas
Normally, I would agree, but in this case the variables represent a real-world object, which is itself very complicated, and to split it up would make maintenance and training very difficult, and I would still have the problem of multiple initialization, just spread around!
Byron Ross
If the variables represent a real-world object then encapsulate that state into... an object. That's why we call them "objects"! :-) Then you can initialize the state in the constructor of the object, where it belongs.
Eric Lippert
Sure, that's what is happening! But it still *needs* to be initialized, to non-default values. Which means someone (_me_) has to do all the finger work... :)
Byron Ross
To clarify, it's one object, that needs to be initialized...
Byron Ross
A: 

Lets say all your "variables" are actually fields of a POCO (plain old CLR object, that is, and object that serves no purpose but to hold data).

class State {
    public double pression_top;
    public double pression_bottom;
    /* hundreds and hundres of fields */
}

In that case, you could do something like:

var myState = new State();
var t = typeof(State);
foreach (var field in t.GetFields()) {
    field.SetValue(myState, 1);
}

Note however that this code is not optimized, and not very concurrency-friendly.

Bruno Reis
I'll try it out. All the initialization happens up front, before concurrency becomes an issue.
Byron Ross