a) My first question is why would you need methods that are not attached to an event?
Is it because rather that retyping the code, you can use a reusable code in a general method and call it from both events? Am i even going the right direction in this?
b) So at the end of the chapter review question, I have to write a method to calculate and return the average of 3 decimal values here is what I have:
private decimal averageDecimal (decimal decNum1, decNum2, decNum3) { decimal decAverageDecimal = (decNum1 + decNum2 + decNum2) / 3 avgTextBox.Text = decAverageDecimal.ToString(); }
Is there anything wrong with this?
bi) If the numbers are stored in variables decNum1, decNum2, decNum3, is it correct for me to declare it at the start like:
//declare variables decNum1 = 10m; decNum2 = 15m; decNum3 = 25m;
and continue with the rest of the methods like above?
P.S. I am new at this whole c# programming thing and I am trying my best at trying to learn it so I am sorry if I come out as clueless or anything because I really am :/
Thanks for reading!
Method is a far more basic concept than event, the cornerstone of procedural programming, before OOP or event-driven programming are a thing. So yes, you’ll use method to use them anywhere you want, be it from your event handler or others.
Your method shouldn’t even compile, you need to return the average. And don’t set the textbox value inside that method. Separate UI & logics. Your code is tied to the UI, modifying the UI would require modifying your method even though they don’t have to be linked.
Not really sure about “the start”. Have you learned about scopes? The variable doesn’t have to be declared at the start, as long as they’re available when calling your method. Oh, and they don’t have to be named the same as the parameters, only the type needs to be equal or at least implicitly convertible.
Hey, lets start from the top
a) One of the reasons you’d want to write methods is to be able to do the same task multiple times in your code without having multiple copies of that code in your project. Like for example later, you want to have a method that works out the average of some numbers. Its possible you might want to do this elsewhere later on so instead of writing it again you can just call the method.
Also this is good for code maintainability, imagine you later discover your average number method has a bug in it and produces incorrect values. If its in a method you only need to make that change once, whereas if you have copied it around your project instead you would have to look for everywhere you have previously copied it to.
b) Your method looks fine at a glance, however I think there’s a missing semicolon after your calculation. In your main code then you would call that method with…
double avgNum = averageDecimal(10,15,25);
As a follow up that method is not very versatile, as it can only work out the average of 3 numbers, something you could look into would be to allow the method to take in a collection of numbers and use that instead. That way you aren’t limited to how many numbers you can calculate the average for.
a) yes, if you think the code can be reused, group it in a class with other methods that might relate to the same domain or share some state. You can chose to put your logic in the event handler, and that’s fine. A lot of times I would do this especially for small programs. But also arranging code is for yourself, or other people. Code clarity in many cases is just as important as code quality.
b) I wouldn’t set the text value in the method that does the calculation. Try to separate UI logic from domain logic. The domain of the calculator is to calculate. Have a separate method for it, returning the result. If you chose to process the result some more, or display it differently, you don’t have to change the method. The logic stays intact.
bi) I don’t know what you mean exactly, maybe you can post what you have (use the Code Block feature of the editor. it’s in the “…” or use markdown mode and put 3 backticks (to the left of 1 on the keyboard). It only works in markdown mode
“`
private decimal averageDecimal (decimal decNum1, decNum2, decNum3)
{
return (decNum1 + decNum2 + decNum2) / 3;
}
“`
becomes
What is 0+0+0/3
a)
When we’re taught OOP, it’s supposed to sort of start with the concept of objects. Think about a coffee mug. If you want to describe it, we can categorize things we know about it into two groups:
Data about the mug like its color, its volume, its weight.
Things we can do with the mug, like filling it, emptying it, or drinking from it.
We call the data “properties”, and the things we can do to or with the mug “methods”.
This is harder to see in a smaller program. In a very simple WinForms/WPF application, you might think event handlers are the only way we call code. But consider something like “downloading a file and displaying the data” in a more complicated application. The process might be like:
Display a “busy” icon.
Use another class to connect to the internet and download a string of data.
Use another class to parse the data into objects we know how to display.
Display the new data.
Hide the “busy” icon.
Each of the bold words might be a method we call on another class. Imagine if in your web browser you had to hit Enter to confirm loading every element on your screen, that’s what a world where only events can call methods would be like.
b)
No, this method is bad. It says it returns a decimal, but instead it stores its result in a text box. It should look like:
private decimal averageDecimal (decimal decNum1, decNum2, decNum3) { decimal result = (decNum1 + decNum2 + decNum2) / 3; return decimal; }
Here’s some tips:
Don’t name variables like decAverageDecimal. First, you put the word “decimal” in there twice. First, you put the word “decimal” in there twice. Next, what else would the result of averaging three decimals be? If you think you need help remembering what type your variables are, they have bad names. If you disagree, the proper name would’ve been thisVariableIsA96BitFloatingPointNumberRepresentingTheAverageOfThreeOther96BitFloatingPointNumbers. If you want to be explicit, be explicit!
The one exception to this rule is people like to name their controls things like txtFirstName or lblHeader. I don’t like it so much, but it’s much more commonplace and it’s better to do what people expect than what you think is right.
Don’t write helper methods like this that directly update the UI. The best first lesson you can learn is about separating UI and logic. If you start doing this today, you won’t have to retrain your muscle memory again in a couple of years. The reason is simple:
// Does this update the UI? We have to go inside of it to find out. // That means it takes us longer to know what it does, thus it is // harder. averageDecimal( decimal.Parse(txtInput1.Text), decimal.Parse(txtInput2.Text), decimal.Parse(txtInput3.Text), );
// In this case, we are more certain the method is just a helper, and // we’re explicit about where we update or use the UI. This is easier // to read and required if we ever want to be experts. decimal input1 = decimal.Parse(txtInput1.Text); decimal input2 = decimal.Parse(txtInput2.Text); decimal input3 = decimal.Parse(txtInput3.Text); var result = averageDecimal(input1, input2, input3); txtAverage.Text = result.ToString();
That last part is interesting: most people assume if you can do your work in fewer lines, your code is easier to read. Unfortunately, we’ve tried that for a few centuries if we include mathematics in our discussion of computer science, and it’s almost always easier to know what’s going on if we include a few more details in our discussion. Have a look at the book Code Complete, it has entire chapters about this phenomenon.
bi)
It is debatable but possibly “bad” to do this.
In a small program, where this is all you do, the argument doesn’t matter. Small programs get to break some rules because if we wrote them “correctly” we’d spend more time on ceremony than it takes to finish the program without the ceremony.
In a larger program, where you might do many different things with many different inputs, it gets hard to remember if the inputs for “add” are decNum1 through 3 or decNum18 through 23. When it’s easy to use the wrong inputs for an operation, you’ll make a mistake.
So it’s better to:
Declare variables as close to where they are used as possible, with as small a scope as possible.
Use names like describe what they do, like averageInput1, instead of names that describe what they are, like numberThatIsADecimal1.
C# devs
null reference exceptions