Best ways to increase your LOC
-
Recently came accross this assertion code:
if (value < 0)
{
ASSERT(false, "Value is smaller than 0");
}
Eventhough the if will probably be optimized out when compiling without assertions, it's still a great way to increase your lines of code :-)
-
Well...
In VB6 you where not able to save a breakpoint.. So you had to rely on Assert statements in your Code if you wanted to persist a breakpoint. The Only WTF I see is that the Assert itself was stuck into a IF... You should remove the IF and stuff the condition into the Assert....
-
My coworker is using some auto-generated C# for a project, and it is very effective in producing extra lines of code. His code for properties look like this:
public int UserID{get{return userID;}set{if (value != userID){userID = value;}}}It should look like this:public int UserID{get { return userID; }set { userID = value; }}But I guess that extra check to make sure the value is not the same as what's already stored may save the computer-intensive work of [i]variable assignment[/i], should the situation arise.
-
[quote user="the_eternal"]
Recently came accross this assertion code:
if (value < 0)
{
ASSERT(false, "Value is smaller than 0");
}[/quote]
Nice
-
For a simple pass-through like this I tend to write it as ...
public int UserID { get { return userID; } set { userID = value; } }
Since that code isn't doing anything semantically important, it's best to get it out of the way so I can see the code that does something useful instead. (Of course, if the setter actually does some validation or something, I format it more conventionally.)
-
@Bob Janova said:
For a simple pass-through like this I tend to write it as ...
public int UserID { get { return userID; } set { userID = value; } }
Since that code isn't doing anything semantically important, it's best to get it out of the way so I can see the code that does something useful instead. (Of course, if the setter actually does some validation or something, I format it more conventionally.)Nice, one-liner :) I usually don't go that far in C#... but anyway the real WTF in the code I posted is this:
if (value != userID) { userID = value; }
-
[quote user="djork"][quote user="Bob Janova"]For a simple pass-through like this I tend to write it as ...
public int UserID { get { return userID; } set { userID = value; } }
Since that code isn't doing anything semantically important, it's best to get it out of the way so I can see the code that does something useful instead. (Of course, if the setter actually does some validation or something, I format it more conventionally.)[/quote] Nice, one-liner :) I usually don't go that far in C#... but anyway the real WTF in the code I posted is this:
[/quote]if (value != userID)
{
userID = value;
}
Two things... One.. I think that puting the entire getter/setter stuff on one line is dumb. The entire point of formating is to create a uniform readable set of text. changing the format in special cases kind of goofs up uniform rule (some might say its more readable though).
Two. The "if (value != userID)" might be an important test, if the setter stmt ends up copying the code instead of copying the reference. What happens if you userId happens to contain an image for instance? its not worth wasting the time copying if its not needed.
-
One – I realise some people might not agree, but I think in the case of a property that is actually doing nothing apart from providing direct access to a field, it's just a waste of screen space to give it any. Even worse, if you have 20 properties, 18 of which have no logic in the setter, it's much harder to see the two non-standard ones if you expand them all.
I recognise I have an unusually compact style, though. It's what comes of being brought up with terse languages like APL where whitespace is strictly optional, and coding in the DOS editor with no syntax colouring and 25 lines at a time.
Two – not in C# (at least, not if I understand you correctly), unless the type is a large value type (
struct), which is a WTF in itself as Microsoft explicitly say you shouldn't do that. Reference types (classes) are always just copying a pointer.
-
@mlathe said:
Two. The "if (value != userID)" might be an important test, if the setter stmt ends up copying the code instead of copying the reference. What happens if you userId happens to contain an image for instance? its not worth wasting the time copying if its not needed.
Most properties are simple value types, and those that are classes are passed by reference. There is really no performance loss that will ever be encountered in the real world usage of this code.
-
[quote user="djork"]My coworker is using some auto-generated C# for a project, and it is very effective in producing extra lines of code. His code for properties look like this:
public int UserID{get{return userID;}set{if (value != userID){userID = value;}}}It should look like this:public int UserID{get { return userID; }set { userID = value; }}But I guess that extra check to make sure the value is not the same as what's already stored may save the computer-intensive work of [i]variable assignment[/i], should the situation arise.[/quote]This makes sense if there's the possibility of assignment being overloaded to do something expensive. (Maybe some sort of validation?)
