Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm just learning java, I found calling methods two ways the both work, but I'm not sure if there is a preferred way.
/**
* This method is called when the order button is clicked.
*/
public void submitOrder(View view) {
int price = calculatePrice();
String orderSummary = createOrderSummary(price);
displayMessage(orderSummary);
}
vs
public void submitOrder(View view) {
displayMessage(createOrderSummary(calculatePrice()));
}
would this be considered poor code? or wrong in anyway?
There is no standardized approach of invoking methods in a certain fashion.
It all depends on the developer writing the code or the team in your work place in general.
One of the most important factors to consider would be how readable your code is. If one approach is more readable than the other, then you could go with that.
Remember that when you develop code, especially at work, there would be several other developers who would maintain code in the future. So, readability and clarity and maintainability of code becomes important.
Hope this helps!
It's not wrong, but the second way is definitely harder to read and understand.
The first method is preferable as it will make your code much easier to understand and debug by you and others
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I was using this code to create some sort of a universal changer class:
//constructor method
public Change(Object affdObj, String affdField, float modifier) {
obj = affdObj;
//...
affectedField = affdObj.getClass().getField(affdField);
//...
affectedField.setFloat(obj, affectedField.getFloat(obj) + modifier);
}
But then I was advised to avoid reflection whenever possible since it's very slow. I was suggested to pay attention to interfaces. Unfortunately I can't see how to fit interfaces to my code.
Hence my question: if one needs to access a field which name he doesn't know in advance are there any options other than using reflection?
PS
Thank you for replies, guys.
And since my question is put on hold as primarily opinion-based, I consider this to be the answer to my question, i.e. there is no other way to achieve my goal which is better than mine in every aspect. In other words, I conclude that my approach is OK. Thank you.
First of all, reflection is not slow (anymore) and is widely used (Spring uses it, Hibernate uses it, etc.). So, you use it with confidence if your only concern is speed.
Regarding other ways to do what you want, since you provide the field name as as a string and identify it like that, you cannot do it with interfaces.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I recently started a project in Java, that contains a class called System. This class (Luckily) contains methods for output management, so in the rare cases where I need to use the System. methods (Or the System object in general) I just reference it as java.lang.System.. I believe that this could be looked down upon, as System could be looked at as a reserved name. I currently am in the beginning stages of this program, and could change it accordingly quickly, as there are little calls to the class itself.
While it's not illegal, you don't want to do this. If I were the next person working on your code, the first thing I would do is try to remove "java.lang" from "java.lang.System" and then get miffed when it wouldn't compile.
The idea is to go toward brevity and only write what you need to write, while making sense of it all for the next person. It's more an art than a science.
You could always name it something like ProjectnamehereSystem or OutputManager or something to that effect.
I would not create something so similarly named as an important class. While everything is easy to edit, you may be able to keep up with all the changes you are making.
But when the project evolves things will get messy and complex. I would suggest naming it something else that can be easily distinguished.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
This is more of a conceptual question than technical pertaining to Java. I've noticed lately programmers tend to avoid creating classes to pass data around and simply move it using JSONObject if available or a basic HashMap. A lot of new interviewees choose to use what I call a JavaScript method of coding. So instead of creating class called Address, they would store it all in JSONObject/HashMap and pass it around as Object later casting to appropriate type. Also I notice a lot of
try { ... }
finally { return str; }
structured methods.
Is this something normal and accepted these days? To me, it just goes against everything I was thought in school. I mean, no generalization, no encapsulation, etc... And when asked, they claim JSONObject is encapsulation. Well, not disagreeing, but just not something expected.
The task is always being done in the end, but the way its done is disturbing to me. This kind of practice produces a lot of loose structures with a lot of potential errors if programmers are not careful. Wasn't java generics created to avoid exactly that?
Feel free to move this question to other exchange, but I'd really like to hear some opinions from seasoned folks.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've been running through a lot of code reviews and keep running into a situation where I see conflicting coding standards regarding boolean variables and if statements.
Here is an example of one method(1):
boolean isXTrue = getBooleanValue(DataSetX);
if (isXTrue) {
//do code
}
Here is an example of the other method(2):
if (getBooleanValue(DataSetX)) {
//do code
}
Both do the same thing and function just fine. In some cases, method 1 is a lot more readable since the boolean variable can be named something meaningful, while method 2 saves more lines and unnecessary boolean variable creations.
Maybe I am reading too deep into a simple coding standard, but I'm rather curious that if we use method 1 more often, we could have unnecessary booleans being made.
Sorry if this is a stupid question, but I wanted to get some opinions anyway :)
It's likely that the compiler will optimize both cases so that either way is identical at run time. Of course, that depends on code outside the context that you've provided.
As for the question at large: it's something that you and your coworkers or group need to come to a consensus about. If you're looking for a definite answer about which one to choose, I don't think you're going to get anything convincing other than personal preferences of readability vs line count.
Discuss this with the others that maintain your code base and decide on which should be preferred. Clearly explain why. Then move on to more...err...important issues.
As for my preference? I like option 1. To me, it's more readable, the variable name can be something descriptive like isActive, which makes the code easier to read. Also, inspecting values during debugging is probably easier as you have a definite variable with which to reference prior to its use later in the chain. Again, that's my preference.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
We are learning about both of these things in Java class right now. I believe I understand the basic aspects of both, but not sure about how Casting ends up limiting Algorithm Reuse. Our teacher said we need to know this for the test next week. Can anyone explain this?
If you cast you are limiting your algorithm to only work with one Class (or it's children). If you were instead to use an Interface you would be able to accept a greater variety of Objects that themselves implement that Interface. Much more flexible.
Here is a related SO question: Explaining Interfaces to Students
When you use casting in your code, you must know the exact type that you cast to (during the code write phase). Hence your code can't be reused in the future with different types. Always remember to program to interface instead of to specific type.