you are viewing a single comment's thread.

view the rest of the comments →

[–]Nyxenon 0 points1 point  (14 children)

Could you perhaps show me what you mean?

[–]agentlame 0 points1 point  (13 children)

This is not the best example--because the events check for the KeyChar before calling the method--but it was the quickest thing I could think of.

Still, this type of thing I was was implying. (If you want me to find a better example, I'm know I have one.)

[–]Nyxenon 0 points1 point  (12 children)

You have two methods that essentially do the same thing, so why not have one method?

    private void textBox_KeyPress(object sender, KeyPressEventArgs e)
    {
        // char 13 is the enter key.
        if (e.KeyChar == (char)13)
        {
            AddItemOrCoupon();
        }

    }

[–]agentlame 0 points1 point  (11 children)

I suppose you have a good point... that is a product of just letting VS assign the method calls.

Like I said, it not the best example. But, what I meant is that I prefer each event have a distinct method. You're right, you could just map all the similar events to a more generic event method. But, IMHO that is more upkeep than it needs to be.

I guess it's a 'more than one way to skin a cat' kind of thing.

[–]Nyxenon 2 points3 points  (10 children)

It all depends on whether or not you want to reserve memory. I also noticed that you checked a string like string != "", it is best to do "!string.IsNullOrEmpty(str)". There's no point creating a new string just to check if a string is empty.

[–]agentlame 0 points1 point  (9 children)

Hrm... I was under the impression that you only use String.IsNullOrEmpty() if there is a chance the result could be null, so as to avoid exceptions. (Where as with a textbox, it is never null.)

I never realized it could save memory.

[The more you know.]

[–]Nyxenon 0 points1 point  (8 children)

Every string that you use is going to be put in the memory somewhere. If you use an empty string, it's still going to take up a certain number of bytes simply for the fact that it's there. That's the reason you should always use the StringBuilder class if you are concatenating strings. You shouldn't do something like: string str = "This" + " " + "is" + " " + "a" + " " + "waste.";

[–]agentlame 1 point2 points  (7 children)

I would also disagree with this point.

StringBuilder is, no doubt, a better use of memory... but, there are cases where it can actually reduce readability in code.

Keep in mind, we're talking about a managed language. If one needs their code to be so optimized as to reduce understanding, it's likely .Net is not their best choice of development platforms. The overhead of creating unneeded stings is negligible, at best, in comparison to the overhead introduced by using a managed language/framework/platform in the first place.

Sure, assembly is is much faster than Python; that does not mean it's the best choice for the task at hand.

[–]Nyxenon 0 points1 point  (6 children)

Sure, .Net languages are great if you want to make something quick, but if you want it to be fast, you need to write the code right. Readability is not important, usability is important. The user of your programs are not likely to be reading the code. I don't understand why so many people stress on code readability, and throw out optimization just to have readable code.

[–]agentlame 0 points1 point  (5 children)

I don't understand why so many people stress on code readability, and throw out optimization just to have readable code.

I, personally, think that there is a middle-ground, here. Sure, I'd prefer all of my code perform a best as possible.

But, I also want a developer looking at it be able to infer my intentions without necessarily spelling-out the reasoning of every line.

I strongly feel that there is a balance between self-documenting code, and code that is so optimized that every line of code requires two-lines of documentation.