Develop Reference

My team mate seems to be offended often when I review his code [closed]

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
My team uses Scrum and we have code review (using Fisheye crucible), but from my observation working together for 2 years is that they care less about good code quality.
I am trying to learn code quality from reading Clean Code, and try to apply things I learn in code and by giving code review. I also had one sharing session on Clean code with my team and hoped that we all follow a good coding standard. Except me and another guy in the team, the rest are not interested in good coding practice nor the term Clean code at all.
I sense a great conflict during code review if I am the one who review my team mate's code. The is one guy that making the conflicts are so badly which I am getting tired of reviewing his code now, eventually I try to avoid a heated discussion that leads to nowhere.
Below are several examples in the my review for his code:
Asking him to create a variable with meaningful name for a magic number that was randomly put in code.
Asking to remove hard-coded values.
Asking to remove duplicate codes (for a particular business logic) in almost everywhere in one class, by asking him to create a method for those duplicate code instead (this time he commented in my code review that: "I could not do it because of this and that, why don't you just do it instead of asking me?" I told him I am a reviewer and not an author of the code and as per our standard the reviewer should not modify the code as she/he likes.)
He used static variables a lot, without any particular reasons. Even in unit tests, public static variables are declared many in the test classes. So I reviewed and put my comment asking to remove static variables instead; or if it is really needed then I suggest to have a #AfterClass method to destroy static variables when not being used (I said it's good for GC). He commented back, kind of: "Having these static variables won't cause any problems to GC for just running unit tests. Why he has to care for GC in unit tests?" and refused to change. My initial intention was that not only in unit tests, but also in production code too that we should not declare static variables as whatever we want.
His method is generally very long, contains of different logic putting in one method. Similar to one unit test method, generally just have two unit tests: one for failed case and one for successful case. So the failure conditions are all putting in one method and the rest are for successful case being put into one method. So when I reviewed, I asked for splitting each possible business logic for testing in one smaller method, and he refused to do so a few times.
My questions are:
I think he gets offended or I get him wrong?
Is there any of above examples I gave wrong comments?
Did I step on wrong line that I really offended him without me knowing?
When you have similar situation for 2 years without getting code review process improved, what would you do?
I tend to avoid reviewing his code and instead work on other stuffs on the board. Is that okay?
I do care for code quality as much as I can within my knowledge, it's a way to maintain a good product and also help myself to learn and improve technically. But getting into heated discussions and sometimes I feel annoyed for his comments are something I wish to avoid. But avoiding this situation for long is not a good solution I think.

coding style :curly bracket after if statement [closed]

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.

Styleguide when coding in a static language [closed]

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 am currently a junior engineer and keen on learning best practices and expanding my experience. My question concerns any static programming language such as Java, C#, C++ etc.
When I am writing code, I like making it easy to read. In my opinion, reading code should be like reading a book. It should be fluent and elegant. Then, even if I do not need to use them, I like prepending this, super–base keywords whenever I can. Ditto for current class name when I want to use constants or static variables/methods.
Consequently, another developer can quickly have a long shot. He knows this method or var is in the current class or in mother class without needed to move to declaration. You may say to me it is really easy to do that with recent IDE. However, I know a bunch of guys who are still working with Vim, Emacs or other editors without these fancy features.
When explaining it, I like comparing my practices to a drama book. We have all read at least one of them, such as Macbeth from Shakespeare. Who has never felt frustrated to go back at the beginning of the book to know who is that character and what part he has in the plot? You did that so many times, right?
My question can be associated to literate programming practices. However, I assumed Donald Knuth's recommandations are more about commenting and adding macros to your code.
So I would like to know your opinions and feedbacks about these practices. Am I doing too much? Should I keep it simpler? Am I breaking OOP rules?
Here is a code sample:
class Bar {
protected int _motherVar;
public aBarMethod() { }
}
class Foo extends Bar {
private static List<String> _strings;
private int _myPrivateVar;
public void aMethod() {
super.aBarMethod();
this._myPrivateVar++;
super._motherVar -= 2;
}
public static String anotherMethod() {
String outcome = "";
for (String s : Foo._strings) {
outcome += s;
}
return outcome;
}
}

It's a very good thing that you care about this.
At the same time, every programmer has gripes about it.
One of mine is that while modern displays have oodles of pixels, you would think that would mean programmers could see more of their code on the screen.
What it seems to mean instead is that the code is so puffed up with whitespace that the content is pushed off the screen.
This makes the code seemingly more "readable" by giving you less to read :)
Another point of mine is that no amount of readability can make code understandable to someone who isn't where you're at in understanding concepts.
I think an important part of the programmer's job is to educate the reader in the basics of what is being done.
Without that, they just won't "get it".
That's not good, because they may very well decide to re-write it (and break it).

To make your code look nice, first thing you need to do is make correct tabs and spaces, so that the code is aligned just the way that is easy to see how the statements are grouped. Everything else, whether you name the variable 'myVariable' or 'my_variable', is just a matter of your preference. It's also a good practice to comment as much lines of your code as possible. That really helps when you return to your code after some time.

Naming methods a, b, c, etc [closed]

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

Reading source code [closed]

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.