Forums Register Login

Help Cleaning Up Code

+Pie Number of slices to send: Send
Hi guys! So I'm working on a program that requires me to calculate grades for a class. I've figured out the code for everything, but I was just wondering if you guys could help me clean up my code. It's really long, so I'll just post one section of it (because all the sections are pretty similar). Thanks!

+Pie Number of slices to send: Send
I'm curious, what made you think that this code needs to be cleaned up? (It certainly can be cleaner)

I'm trying to understand where it is you're falling short on understanding what's making your code less than "clean." Is it that you "smell" something but don't quite know how to put your finger on what that smell is? Or are you able to explain what the smell is but are not sure what to do to mitigate or eliminate it?
+Pie Number of slices to send: Send
 

Junilu Lacar wrote:I'm curious, what made you think that this code needs to be cleaned up? (It certainly can be cleaner)

I'm trying to understand where it is you're falling short on understanding what's making your code less than "clean." Is it that you "smell" something but don't quite know how to put your finger on what that smell is? Or are you able to explain what the smell is but are not sure what to do to mitigate or eliminate it?



I guess I should've been more clear. When I mean "clean up", I mean, is there a way to make it shorter? 'Cause it's pretty long and our methods are only supposed to be 40 lines of code or less, but my main method will have about 50-59 lines of code once I add the other parts of the program in.
+Pie Number of slices to send: Send
 

Erika Her wrote:our methods are only supposed to be 40 lines of code or less, but my main method will have about 50-59 lines of code once I add the other parts of the program in.


You are right about that.

main() method supposed to be not just less than 40 lines of code, but less than 2 lines of code, meaning only 1 in it. Read our tutorial MainIsAPain about that.

Another thing is, that you don't have any object orientation in your program. Good that you have some methods, nevertheless, some of those do more than 1 thing. Remember, method supposed to do 1 and only 1 thing. If it says print result, that should print result and nothing else, no assignments of values or anything like that.

Have you been introduced to Java as about object oriented language? Have you been told what objects are, what kind of information they should encapsulate, what functionality provide? Which object's responsibility is A, which ones responsibility is B, why not other way round, why not one object should do A and B?
+Pie Number of slices to send: Send
 

Erika Her wrote:methods are only supposed to be 40 lines


Regardless what is said, probably you should aim for no more than 10 lines for a start.
+Pie Number of slices to send: Send
A method should do one thing and do it well.  Name your methods as actions or behaviors, like getGrade() or updateName().  You should be able to see all of your method code on a single, standard screen.
+Pie Number of slices to send: Send
 

Liutauras Vilda wrote:

Erika Her wrote:methods are only supposed to be 40 lines


Regardless what is said, probably you should aim for no more than 10 lines for a start.


This a great goal. However, for a beginner, I doubt it's realistic. I would be pleasantly surprised if beginners like OP can keep their methods within 15-30 lines of code. 40 lines of code may be a bit longer but it's a start.

One key to getting your methods shorter—you really should think small instead— is adhering to the Four Rules of Simple Design. In fact, one of those rules is to "keep your design small" - small methods, small classes, small interfaces, small dependencies, small scope, etc. The smaller you can make the individual units in your code/design, the more focused they are on the one task that they need to do. That's what Knute was saying.

Another key is having proper levels of abstraction. The level of abstractions in your design/code should go from public/more abstract to private/more detail-specific.  High-level public code should be more abstract and general. Low-level code should be where all the nitty-gritty details of implementation should be hidden. An analogy for this would be your car. Your car has a steering wheel. This is a very high-level abstract piece of your car. Don't believe me? What kind of steering does your car have? Is it recirculating ball or rack and pinion? Is it power-assisted? Is it variable ratio? Is it speed sensitive? You don't know anything about what the heck I'm talking about? Exactly. That's because you only know the abstraction of that circular thing that has controls for the volume of your radio and the cruise control. You as a driver only need to know that when you turn the wheel to the left, the car will turn left. If you turn the wheel to the right, the car will go right. That's your abstraction. The detailed implementation is hidden under the hood where you seldom, if ever, go.

The steering wheel in your car has a small API. Turn left to go left, turn right to go right, straighten it out to go straight. That's small. Same thing with your brake pedal. Push it down to stop, let off to go. Two actions. That's small. Notice that each component is responsible for one specific function of operation. Again, that's what Knute was talking about.

If you start with these principles in mind, then you can start cleaning up your code and figuring out, is this functionality part of the public API or is it something that deals with implementation detail? Is this method doing only one thing or is it mixing two or more actions together? Note that when you answer this last question, actions that are related to each other can still be teased apart. You need to figure out what the details are for each action, then figure out what the overall intent is. Then you create a high-level method that describes the intent in an abstract manner and then makes calls to the methods that contain the detailed implementation specifics.
+Pie Number of slices to send: Send
Here's an example of what I mean. Take your main method. I can clean it up by making it more abstract and pushing all the details down to private classes and methods that perform small, focused, detailed tasks.

That code can be refactored into something like this:

If it's not clear to you how all the code in the version of main() that you wrote can be turned into this code, then your brain is trapped in the details of what you wrote. You need to pull yourself out of that trap.

Lines 2 and 3 in the cleaned up code express the intent of lines 3 to 13 of your code. Lines 5 and 6 in the cleaned up version express what your code does on lines 14 to 20.  Lines 8 and 9 in the cleaned up code show how line 21 in your code could be delegated to a class that is tasked with the singular task generating reports about grades, based on data that is held by a DataEntry object that is passed to it to help the reporter object do its job.

Do you see how making the main() method small and abstract makes your code cleaner? Do you see how creating different classes and assigning them specific jobs can make your code and design more organized and logical? How many lines of code does main() have now? That's six executable lines of code, 8 if you count the blank lines between the logical sections. That's a reduction to a little less than half of what you originally had, and it's clearer and more abstract, too!
I am not young enough to know everything. - Oscar Wilde This tiny ad thinks it knows more than Oscar:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 360 times.
Similar Threads
Enter double values into a single line, and then put into an array?
My main class will not display my code
Need help with displaying code to console
In need of much help with my main method.
IllegalArgumentException and an Array Constructor
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 14:03:49.