|
well thats where one good programmer needs to improve his coding practices. Other wise such normal mistakes keep happening. Yep its true that it went to a production code.
Lets not depend fully over compiler, even programmers have to be a bit more smart too
My Blog -> https://adventurouszen.wordpress.com/
|
|
|
|
|
This often happens if you type the method before declaring the variable.
return value; will get corrected by the ide to:
return Value; when the ; is typed.
That does not excuse the original developer for not checking it.
It is also looks far too compressed to me having the entire property on one line, although that is a matter of formatting standards, I guess.
|
|
|
|
|
This is true and extremely annoying. If I wanted a capital I'd have typed it as such, damn you!
I like one line properties if they are doing something simple (as most are); it means there is more screen space available to see actual code. I'm generally in favour of condensing things as much as reasonably practical for that reason, and particularly dislike the C# standard for braces which wastes a ridiculous number of lines.
|
|
|
|
|
I'll use one-line properties if they're automatic: public Type Value { set; get; } , but otherwise they are:
public Type Value
{
set
{
_Value = value;
}
get
{
return _Value;
}
}
private Type _Value;
Software Zen: delete this;
|
|
|
|
|
The only sound rule that applies to all processes, standards, and approaches is the following:
"The only rule, is that there are exceptions to all rules"
I was talking to my coworkers (all former contractors) about SVN and when to commit, some said "on save", others "end of day" and of course "when I am done". This is interesting to me, that not everything is worth committing, and sometimes things are critical, that every line counts. This is just one of those things, we developers are pragmatic. Our careers are in constant Limbo, between heaven and hell, and the fragility is an ever-present reality. I am sure you have your own examples.
modified 5-Jan-12 14:48pm.
|
|
|
|
|
Reminds me of this old chestnut...
"All Generalisations are wrong, including this one!"
------------------------------------
I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
CCC Link[ ^]
Trolls[ ^]
|
|
|
|
|
I hate all generalisations!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Almost all generalizations are stupid.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
This not the place to post that.
|
|
|
|
|
When it comes to source control, there is one rule that should never be broken. Don't commit code that does not compile.
"You get that on the big jobs."
|
|
|
|
|
I prefer "Don't commit code that hasn't been tested"
I don't regard source control as an alternative to a good backup regimen!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
As the source control administrator for my group, and the author of our automated build process, I've yearned for a wee bit of hardware that I could control.
I would like the ability to kill anyone who checks code in that breaks the build. Electrocution through the keyboard, a guillotine that dropped down from the ceiling, a trap door that dropped the offender into the building incinerator.
My favorite would be Lucite walls that would close around the offender's cube, and then fill the cube with nerve gas. Of course, this gives you the option of leaving them there for a day or two as a reminder to others.
Software Zen: delete this;
|
|
|
|
|
Cruise Control can be X10 automation enabled for exactly this kind of thing.
|
|
|
|
|
Too bad we don't have any interns on hand to use for debugging the thing...
Software Zen: delete this;
|
|
|
|
|
I just found the following code
if (Name == "Ticket")
{
IngGenInvPs post = new IngGenInvPs(taxBO, "Ticket");
}
else if (Name == "Advertisement")
{
IngGenInvPs post = new IngGenInvPs(taxBO, "Advertisement");
}
else if (Name == "Asset")
{
IngGenInvPs post = new IngGenInvPs(taxBO, "Asset");
}
else if (Name == "Telecom")
{
IngGenInvPs post = new IngGenInvPs(taxBO, "Telecom");
}
else
{
IngGenInvPs post = new IngGenInvPs(taxBO, "Inventory");
}
|
|
|
|
|
It's not that bad!
Well, yes, you could do it with a switch:
IngGenInvPs post;
switch (Name)
{
case "Ticket":
case "Advertisement":
case "Asset":
case "Telecom":
post = new IngGenInvPs(taxBO, Name);
break;
default:
post = new IngGenInvPs(taxBO, "Inventory");
break;
}
Or preferably, just remove it as all the created variables go out of scope at the end of the block - unless they are being sneaky in the constructor!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
ok,
how about this
IngGenInvPs post = new IngGenInvPs(taxBO, Name);
|
|
|
|
|
And if I prefix that with
Name = "Hello, this is a lot of rubbish!";
IngGenInvPs post = new IngGenInvPs(taxBO, Name); Does your code give the same result as the original?
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
It probably does in the context of the requirement. If you require fixing to a small set, firstly it should be an enum not a string input, and secondly if there is a good reason to allow free text input it's still better to have a simple check along the lines of
if(!ValidNames.Contains(Name)) throw ...;
... and then just construct the object from the name.
|
|
|
|
|
+5
|
|
|
|
|
psst! Use the markup <pre> to make your code purdy.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Not a shame IMO.
Having a bunch of if-else or a switch-case setup is the simplest and most straight forward to do this for five to six cases. The conditionals could be moved inside the constructor to make the code more readable though.
modified 3-Jan-12 8:51am.
|
|
|
|
|
bosedk wrote: The conditionals could be moved inside the constructor
I hope not!
This would only be advisable if the differentiation between the 5 strings were something inherent to that class, but then OP should have used an enumeration instead of strings.
Regards,
Manfred
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
Manfred R. Bihy wrote: I hope not!
Aah, yes. I now see why not!
Manfred R. Bihy wrote: but then OP should have used an enumeration instead of strings.
the text might be coming from user, who knows, so converting text to enums and checking against the enums would be additional no value added steps for the simple scenario.
But without proper context, the code seems alright.
|
|
|
|
|
"Training" is usually something you can only do in your free time, during the times you should be sleeping. At work you have to deliver stuff.
If you have a limited amount of time to deliver something that works and you're not yet quite experienced (and without any formal education on software development), then this sort of stuff happens.
It's not pretty but it works... for now...
Giraffes are not real.
|
|
|
|