Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Lots of times I see people naming their methods a(), b(), c(), etc. instead of giving them names that describe what the method actually does. What is the point of this?
My guess is that you were reading obfuscated code.
Here's a nice article.
They shouldn't be doing this. It's bad practice.
Either the developer is being lazy, or they are showing a very simple example(still bad practice).
EDIT: (Given the extra detail in your comments)
In that case this is probably done by some automated program. The code the developer is actually working on wouldn't be using these names.
To minimize the load time for .js files, many developers will "compress" them. Compressing also has an option to obfuscate the code, making it more difficult to steal and change by making it difficult to understand. This happens just as you describe, by changing the variable names and function names to "a", "b", "c", etc. This has the side-effect of making the code smaller, since the names are now shorter. An example of a web tool that does this for you is here: http://www.developerfusion.com/tools/compressjavascript/
The code base that you maintain is certainly NOT the one that has been compressed and/or obfuscated.
Nothing. They are just too lazy to follow the standard naming conventions maybe because they are simply doing some quick POC(proof of concept) and they don't want to waste their time in typing some meaningful method name.
But one must always follow the naming conventions in their actual projects where others might be looking/maintaining their code.
This has always been discouraged by every community into programming and probably is a sign of a bad developer.
For more information on why and how do we use coding conventions see this
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 3 years ago.
Improve this question
I am curious to know the current coding style for java. My team is forcing to use {} for one liner if statements. Although we used to have braces for one liners current java source code does not use braces for one liner if statements anymore and I myself am inclined towards the same.
Python dropped braces altogether.
However I do not see any particular style guide in 2019.. The oracle doc still refers to the 1997 coding style.
What would be correct coding or is it something more to do with developer's preference?
foo();
if (condition)
doSomething();
bar();
vs
foo();
if (condition) {
doSomething();
}
bar();
Edit 1: As Kartik mentioned we can write one liners like this as well:
if (condition) doSomething();
For me, it as a developers preference and I am ok with both the approaches but in my current team some developers are of opinion not using braces is a BAD coding practice. I saw the java source code and found in many places braces are omitted. So, I don't believe this to be true. As for google coding style, it was also there for many years and many people continue to use the same. But for new code are there any new guidelines?
Edit 2: This question is marked as opinion based and put on hold
I want to clarify that I am NOT looking for opinions. I am more looking for standard guidelines which Oracle (or java open source communities) might have put forward regarding best practices as of today (2019). Most practices java/google are very old dating back to 1996 and may not be relevant today. Even if there is some reference in some new books and some can share those details it will be very helfpul
I think one of the commonly used style guides for java is the one from Google, see here.
It says:
Braces are used with if, else, for, do and while statements, even when the body is empty or contains only a single statement.
But the real general answer here is: only use such input as hint what to do. For you: sit down with your peers, and check out what you like, and then write that down, and go with it. Like: our team decided to use the google style, but to make subtle changes to it here or there.
And then make sure that your tooling supports your preferred style. One of the reasons why we selected "google style" is the fact that you get formatting templates for eclipse, IntelliJ, and even SlickEdit.
I agree that there are no "prominent" style guides for Java8 (and newer) elements, such as lengthy stream statements. That is where "decide with your team what you want" comes in again. We decided for example that
stream()
.filter(...)
.whatver
each go on their own line (one reason for that is the fact that IntelliJ will then give you the return type of each line right there while editing, what I find extremely helpful when working with streams).
Write as you like. I prefer brackets.
They help navigate the code.
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
which coding style is better and what are the types of people in image programmers will know
which is better as a good programmer?
First writing curly braces after if statements - or curly braces on new line after if statement?
if(condition){
}
if(condition)
{
}
Although this is very much a matter of style, the "Java way" of doing it has always been to put the opening brace on the same line as the statement it is attached to. So
if(condition) {
}
is the suggested way of doing it. Who suggests this? Well, Sun did (and now Oracle maintains that page, too). And Google does.
I'd say that it's up to you to decide, which one suits you best. Also, from what I know, some languages are encouraging to use specific style:
Java preffers camelCase and
if (true) {
}
C# PascalCase and
if (true)
{
}
However, it's important to keep style consistent in project. If you mix styles in single file / project, that's bad practice.
As other has written, there are certain standards that promote
if (whatever) {
}
as the "better" solution.
In that sense, "better" actually means:
the majority of Java programmers is used to this style
therefore, for the majority of programmers, it will be easier to read code that is following the common styles
or vice versa: if you deviate from the common standards, everybody reading your source code will burn unnecessary brain cpu cycles to accustom to that deviating style
(and keep in mind: normally, source code is written "once"; but read maybe hundreds or thousands of time. thus "wasting brain cpu" is a serious issue)
But, on the other hand, the answer is: it depends.
My personal experience is: if you are following a consistent style, then the details of that style do not matter too much. You see, if your company has its own style conventions; and everybody is following those ... then you have to adapt. Period. And honestly: it is not that hard. I was asked to use all kinds of style conventions. And you simply adapt. It might take some time, but in the end, you will have no problems reading/writing code that maybe says
if (whatever)
{
So, when your team says: for our own good reasons, everybody has to use that second style, then that's it.
But if you are working on open source, or you are the person defining the style to use - then simply stay close to the "official" conventions from Oracle.
And final note: code formatting is a tooling question. You make sure that you specify your style convention so that your IDE can enforce it. Then you are even free to use your very personal style - just reformat source upon checkout; and turn back into "other peoples style" prior checkin to you source code repository.
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 7 years ago.
Improve this question
I am used to programming in static languages like Java, where changing the signature of a method will cause a compilation error for every line of code that calls the method I changed. This makes modifying large projects much more easy, because I can make a change, and then let the compiler tell me about all the places that I need to fix.
When dealing with a large project in a dynamic language like Python or Ruby, how do you make code changes, and still remain confident that you are not going to be surprised with a run-time error in production because of some scenario you forgot about?
I've seen my fair share of NullPointerExceptions and ArrayIndexOutOfBoundsExceptions in Java, so it's not like these things never happen in a static language, I would just think they happen a lot less.
Here are some ideas for providing some level of the protection that you are used to in Java:
As stated in a previous comment, you should definitely provide adequate unit and integration testing to prevent any issues during a refactor. Testing is even more important in a dynamic language than in a statically-typed language. You should check that values are properly passed and handled in each of your functions.
Use PyCharm and search for usages on a method prior to making the update. This is not full-proof, but does find a good amount of method usage to allow for an easier refactor.
Do a global find for the method name in your editor or search program of choice.
Provide exception handling in your functions for cases where the type is incorrect or a value is unset.
Handle args and kwargs passed into your function carefully. Perhaps provide an error or debug log if you receive an unexpected input.
Provide default values for undefined parameters to a function.
Here is an example of providing a default value for a parameter to ensure that it is defined and initialized to None (similar to null) in the function if it is not passed in with a value:
def my_function(my_parameter=None):
# Do something with my_parameter
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 need to implement a set of rules in a validation class. Each rule needs to be checked in its own method (because of the ability to configure which rules should be checked). The problem is that the rule names come from an official entity(naming must be preserved) which defined them in the format:
Rule 1.1
Rule 1.2
Rule 1.3
...
Rule 2.29
Currently I am using a format like testRule1_1() , but it does not comply to the official Java naming conventions. How could this be renamed to comply?
Thank you in advance!
I believe that your goal should not be to slavishly follow naming conventions, but to remember their original purpose. The official Java naming conventions are designed to (1) make code more readable, and (2) prevent naming conflicts (e.g., between class and method names). If the conventions are counterproductive to achieving those purposes, it's correct to ignore them. They are only recommendations and emphatically not rules, and even in the standard API the naming conventions are sometimes (deliberately) ignored.
The method name testRule1_1() is unquestionably legal in the Java language, and is readable, and so it is not wrong to use it. Besides, I'm not convinced it is against convention. I don't recall ever seeing written guidance about how to separate numbers in a method name, but you would surely not be the first person to use an underscore.
Just as an opinion, I think testRule1_1() is fine, but I most prefer testRule1x1() as suggested by Joop Eggen in the comments above. Any other word inserted between the numbers as a spacer seems like an unsound sacrifice of brevity, but a simple x is short, and compared to an underscore it is quick to mentally read out.
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 4 years ago.
Improve this question
If you read other people's source code, how do you approach the code? What patterns are you looking for (datatypes, loops, use of control flow, ... )? How long can you read other people's code without getting bored? What is the most exciting patterns that you have discovered so far?
At first, I ignore the urge to change the code. Which is sometimes hard to do. But understanding first and change later saves yourself a lot of nasty "learning experiences."
Next if the format is bad, reformat. Use a code formatter if you have one. This is because you tend to look at the indentation and if that is bad, your understanding of the code is also questionable.
Then, if there are complex datastructures, I like to draw a little diagram. The challenge here is keep it as simple as possible. Large diagrams are fun on the wall, but most of the time, they are to cumbersome to look at. So it is wasted time.
If you finally understand what a piece of code does, write a comment. This is essential, because else you won't understand it the next time you are here.
The following step is to create unit tests. Now you can not only test the code, but you can also test your understanding of the code.
Last, if you understand it al and you know it can (and need to be) better, change it. But be sure to run the tests. Unless you are paid by each solved bug.
A hip new term for this is Code Spelunking.
Aside from the obvious "work from the top down" general approach, it depends on why I'm reading it: code review, trying to understand a bit of avaialable code to adapt for my own use, trying to learn a new technique, etc.
It also depends heavily on the language. If it is an OOPL, I'll probably do something like this:
Look first for the primary class relationships and try to understand the primary responsibility of each class.
Look at the interactions between classes to see how they collaborate.
Look at the interfaces of the key classes to see what "services" they offer their collaborators.
Look inside the non-trivial methods if it's important to understand how they are working instead of what they are responsible for.
thanks, if I understand correctly, first step is to identify the context, second identify API's, and place the API's in context. I just realize it is a bit like looking at a building or piece of art, you could focus on the material used, or the function of parts, try different perspectives, judge how parts fit in the whole... there is a nice piece of the process of discovery: here - how mathematicans think
It all depends on what type of code you are reading. Is it a web app, a service, a desktop app? When I do start reading other's code I usually start looking for design patterns used. Or for the framework-specific things. But again this is if you are doing a review. If you are reading for your own interest and to learn something there really is no answer - you should read and understand the code thoroughly.
Pick an item you understand in the final product and see how it is put together. If you've got the unit tests then they are a great help.