클린코딩/더 나은 코딩을 하는 10가지 방법, 10 Tips for clean code/ better code/ quality code.
Did you ever look into your or your team members code and think ‘What a hack? Why does this method look like a cat was walking on the keyboard?’. If so, then you definitely need to spend some time to clean your project’s code, because high-quality code is easier to understand, modify and scale.
본인의 코드나 팀 멤버 코드를 보고 '이게 뭐여, 키보드를 고양이가 걸어댕겼나 ㅅㅂ' 라고 생각한 적이 있나? 그렇다면, 프로젝트의 코드를 깨끗하게 하는데에 시간을 쓸 필요가 분명히 있다다. 왜냐면 좋은 품질의 코드는 이해하기 쉽고, 수정하고 확장하기 쉽다.
1. Naming Convention 이름짓는 관습
Nobody forbids you to give a name to your methods or variables in your own way but there is a common convention between developers according to programming language they use. So you need to stick to it in order not to make your colleages become angry because of your naming. In this example I will show you the best naming practice from Java perspectives.
All variables, methods and classes should use CamelCase style. The only difference: a first letter of class should be capital:
아무도 네가 함수나 변수를 이름짓던 금지하지는 않지만, 프로그래밍 언어를 쓰는 개발자들 사이에서 공통적인 관습이 있다. 따라서 너의 작명에 동료들이 화나지 않도록 따를 필요가 있다. 이 예제에서, 자바의 관점에서 이름 짓는 연습을 보여주겠다.
모든 변수나 함수, 클래스들은 CamelCase 스타일로 한다. 유일한 다른점 하나는 ㅡ 클래스의 첫자가 대문자이다.
class UserService {
private String firstName;
public String getFirstName() {
return firstName;
}
}
Constants should use all capital letters divided with underscore:
상수는 전부 대문자에 언더스코어로 띄어쓰기를 하는게 좋다.
final int MAX_AGE = 20;
Try to avoid special characters and numbers:
특수기호나 숫자를 쓰는 것을 피해라
//This is a BAD practice // 안좋은 예들
User user1 = new User();
User user2$ = new User();
Don’t use too much words in the variable/method name. It should be as simple as possible, but also informative.
너무 긴 글자를 변수나/메소드명에 쓰지 말아라. 가능하면 심플하게 하면서, 정보를 담아라
//This is a BAD practice // 안좋은 예들
public void saveUserIntoMongoDBDatabase(User user);
//This is much better // 좀 더 나은 예들
public void saveUser(User user);
Use verbs for function names and nouns for classes and attributes.
함수 이름은 동사로 짓고, 클래스나 속성의 이름은 명사로 지어라
2. Write What You Mean 의미하는 바를 적어라
When you create a variable don’t be lazy to give it a full name. Never use only one letter in the name. Variable should represent the value it was created for. Even if you know what this variable is made for, doesn’t mean other developers will understand it. Also when you will come back to a certain block of code after some time you will probably forget the meaning of this variable.
변수를 만들때, 풀네임을 쓰는 것을 귀찮아하지 말아라 (제발!). 이름에 한글자만 절대 쓰지 말아라 (제발!!!!). 변수는 어떤 것을 위한 값인지를 나타내야 한다. 너는 변수가 뭘 위해서 만든 것인지 알더라도, 다른 개발자들이 알거라는 것이랑은 관련이 없다. 또한, 시간이 지나서 다시 본다면, 변수의 의미를 잊어버리게 될 것이다.
Let’s consider the following code snippet: 다음 코드 스니펫을 보자
public boolean check() {
if (a < max) {
return true;
} else {
return false;
}
}
This code is totally unclear, so other developer will definitely not understand what this method does. Let’s make some refactoring and see how it can be written in a better way:
위의 코드는 완전 모호해서, 다른 개발자들은 이 메소드가 뭔지 절대 이해 못할 것이다. 좀 리팩토링을 해보고, 어떻게 더 나은 방식으로 쓰이는지 봐보자.
public boolean isAgeAcceptable() {
if (userAge < maxAge) {
return true;
} else {
return false;
}
}
3. Variables/Methods Declaration 변수와 메소드의 선언
All variables in the class should be declared at the top of the class. Using such approach you will always know where to find the declaration of this variable and will not have to scroll over the whole class (which might contains thousands lines of code) to find where it was declared.
If variable is used only in one method then it would be better to declare it as a local variable of this method.
Methods should be declared in the same order as they are used (from top to bottom). For example, if you are calling some method from your current method then that method should be declared below the current one. Also more important methods should be declared at the top of a class and minor methods at the end.
모든 클래스의 변수들은 클래스의 맨 위에 선언되어야 한다. 이러한 접근은 변수들을 찾을 위치를 언제든 알수 있고, 전체 클래스를 스크롤해서 선언된 곳을 찾을 필요가 없다. (몇천줄의 코드에서)
만약 변수가 한개의 메소드에서만 쓰인다면 로컬 변수로 선언해서 쓰는 것이 낫다.
메소드들은 쓰이는 순서대로 선언 되어야 한다 (위에서 아래로). 예를 들면, 만약 현재 메소드에서 다른 메소드를 호출한다면, 메소드는 현재 메소드의 아래에서 선언되어야 한다. 또한, 더 중요한 메소드는 클래스의 위쪽으로 가고, 덜 중요한 것들은 끝으로 간다.
4. Single Responsibility 한가지만 관련있는 기능 (여러기능 하나에 X)
One method should be responsible only for one action. If your method does two or three different things at a time then you should consider splitting the functionality of this method into other methods.
Such method is easier to understand, scale and reuse in other methods.
For example, you have a method saveUserAndChargeCard() which saves user to database and charges his credit card. This method is definitely bad, because it contains ‘And’ in the name and performs two actions. Avoid using words like ‘and’, ‘or’ etc. in a method name. You should split this function into saveUser() and chargeCard().
하나의 메소드는 한개의 동작에만 관련이 있어야 한다. 만약 메소드가 두개나 세개의 다른 것들을 한번에 한다면, 기능적으로 다른 메소드들로 나눌 것을 고려해야 한다.
그런 메소드는 더 이해하기 쉽고, 다른 메소드에서 재사용하기 쉽다.
예를들면, saveUserAndChargeCard() 라는 메소드가 있어서 데이터베이스에 유저를 저장하고, 그의 신용카드를 청구한다. 이 메소드는 분명 나쁘다. 왜냐면 'AND' 가 이름에 들어가서 두개의 액션을 한다. And 나 Or 등의 글자를 피해라. saveUser() 과 chargeCard() 로 나눌 수 있다.
5. Small Methods 작은 메소드(함수)
There is no a standard pattern for method length among the developers. Someone can say that 10 lines is max size, someone can say 5, in some cases even 20 lines of code is okay. So how to choose a correct one? Ectually, there is no a correct answer. Just try to make your methods as small as possible. The best methods are considered to be from 5 to 10 lines of code. But no one will fight you if your method has 12 or 15 lines, just make sure that these 15 lines of code is understandable and high-quality.
Also if you are writing some algorithm that makes some complicated calculations (or something similar) and it cannot be splitted into smaller methods, don’t worry such cases are also acceptable, but again watch your code quality.
개발자들 사이에 메소드의 길이에 대한 표준 패턴은 없다. 누군가는 10라인이 최대 사이즈라고 할 수 있고, 누구는 5줄, 누구는 20줄도 괜찮다고 한다. 그래서 어떤것을 옳다고 할 것인가? 사실, 정답은 없다. 그냥 최대한 작게작게 만들어라. 가장 좋은 메소드는 5~ 10줄로 여겨진다. 하지만 12~ 15줄이라고 아무도 너랑 싸우지는 않고, 15줄의 코드를 이해하기 좋고 고퀄리티로 만들어라.
6. Minimize Your Code 코드의 최소화
Don’t write three lines of code if the same thing can be done with only one line. It means that before adding some block of code you need to think about the best approach you can apply to this piece of code.
You might create a great functionality and algorithms, but it will not make sense if your code reviewer will ask to refactor your code because he can write the same thing using in to times less lines of code.
한줄로 끝날 수 있다면 3줄의 코드로 풀어쓰지 말아라. 코드블럭을 추가하기 전에 최상의 접근법을 생각하고 적용할 필요가 있다.
최고의 기능과 알고리듬을 만들겠지만, 나중에 코드를 리뷰하는 사람들이 몇배나 적은 코드로 같은 것을 할 수 있게 리팩토링하려고 물어보지 않을 거라는 보장이 없다.
Let’s consider small example: 작은 예를 보자
boolean hasCreditCard(User user) {
if (user.hasCard) {
return true;
} else {
return false;
}
}
At the first look this method seems to be normal, but it can be simplified:
일반적으로 보이지만, 단순화 할 수 있다.
boolean hasCreditCard(User user) {
return user.hasCard;
}
As you can see we have written only one line of code instead of five. So think harder before starting implementation.
보듯이, 5줄 대신 1줄로 끝낼 수 있다. 구현하기 전에 생각을 많이 해봐라
ㅡ 이건 예제가 이상한 듯
7. Duplication Is EVIL 중복은 악이다
Try to avoid code duplication in your project (unless you get paid for written lines of code ☺). If you cannot reuse a method in other place then probably this method is bad and you should consider a better way to write this method. Your methods must be as universal as possible. This will help your team members to use your method instead of writing their own.
For example, if you have two functions that implement almost the same thing and the only difference is one line then it would be better to extract the same functionality into other method and concat these two functions into one with adding some condition checking.
프로젝트에서 코드의 중복을 피해라 (코드 라인 수대로 돈을 받지 않는다면..). 만약 다른 곳에서 메소드를 재사용 할 수 없다면, 잘못된 것이고, 그 메소드를 재사용할 더 좋은 방법을 생각해봐야 한다. 메소드는 가능하면 최대한 넓게 쓰여야 한다. 이것은 멤버들이 또 만드는 것 대신에 재사용을 하도록 해줄 것이다.
예를 들면, 거의 같은 것을 구현한 두개의 함수가 있고, 단지 1줄의 코드만 다르다면, 같은 기능을 뽑아내서 하나로 만들고, 두개를 연결해서 다른 조건 체크를 만드는 것이 낫다.
8. Comments 코멘트
Some time ago comments were considered as a normal practice and almost everyone was commenting a code. But now is considered if you are adding a comment then your code is not self-explaining and you should choose a better way to implement it.
Another issue related to comments is that often developers modify some block of code but forget to change a comment. For example, you created a function which implement some functionality and left a comment about what this function does. Then you or other developer changes function name or rewrites it at all and forgets to change comment. In such case other team members will be confused because the function and the meaning of this function mismatch.
It’s okay to leave comments if your are writing very complicated algorithm and your comments and noted will help other developers to better understand it.
얼마 전에는, 코멘트는 일반적인 연습이었고, 거의 대부분이 코드에 코멘팅을 했다. 하지만 지금은, 코드에 코멘팅을 한다면 너의 코드는 스스로 의미를 설명하지 못하고, 더 나은 구현 방법을 찾아야 하는 것으로 여겨진다.
코멘트와 관련된 다른 문제는 종종 개발자들이 코드블럭을 수정하고 코멘트 수정을 잊어버린다. 예를 들면, 어떤 기능을 하는 함수를 만들어 놓고, 함수의 기능을 코멘팅 해두었다. 너나 다른 개발자가 수정하고서는 코멘트를 바꾸는 것을 깜빡했다. 이러한 경우 다른 팀 멤버가 함수의 기능과 이름이나 코멘트에 대해 헷갈릴 수 있다.
복잡한 알고리즘이거나, 코멘트가 다른 개발자들의 이해에 도움이 된다면 코멘트를 남기는 것은 괜찮다.
ㅡ 매우 짧은 메소드가 아닌 이상, 클래스 설명이나 좀 긴 메소드 설명은 짧게짧게라도 당연히 써주는 것이 맞다고봄.. 불필요한 시간낭비 줄여줌
ㅡ 잘게 쪼개놨을 경우에는 사용법이라던가 전체 로직 흐름이라던가 처리과정이라던가
9. Code checker tools 코드 체커 도구
I would recommend you to use special tools that check your code quality even if you are applying all of the things described above. This tools can scan your code and show you where are some mistakes in your code, because you can miss something doing all of this checks manually.
One of the best tools for this is SonarQube. It’s the leading product for continuous code quality analysis. But if it’s too complicated for you then you can just install some plugins to your development environment.
위의 모든 내용을 다 지켜서 코딩했다고 하더라도, 코드 퀄리티 체크를 위한 특별한 도구들을 사용하는 것을 권장한다. 이 툴들은 코드를 스캔하고 어디를 실수했는지를 찾아주는데, 왜냐면 수동으로 찾다보면 빠뜨릴 수 있기 때문이다.
가장 좋은 툴 중 하나는 SonarQube 이다. 코드 품질 분석에 선구적 제품이다. 하지만 좀 복잡해서, 그냥 개발환경에서 몇몇 플러그인 깔 수도 있다.
ㅡ 광고 같은데..
10. Best practices 최고의 임상(실제로 쓰이고 있는 것들 중 좋은 것)
The last thing I want to talk about is using of best practices. No matter what functionality you are working on I pretty sure that someone has already done it (or something similar) before. So it would be great to make some investigation before implementation of this feature.
Also learing best practices will help you to level up your professional skills and you can share your experience with your colleages.
마지막으로 하고픈 말은 최고의 실제 쓰이는 것을 배우라는 것이다. 어떤 일을 하고 있던지 간에, 누군가는 이미 이전에 했을 것이다(비슷한 것이든). 그래서 이러한 것들을 구현하기 전에, 조사를 먼저 해보는 것이 좋다.
또한, 최고의 임상을 배우는 것은 전문기술을 레벨업 하는데에 도움을 주고, 네 동료들과 경험을 나눌 수 있을 것이다.
Conclusion 결론
Thank you guys for reading. I hope you enjoyed it and learned some new stuff. Please subscribe and press ‘Clap’ button if you like this. And don’t forget to clean your code!)
읽어서 고맙고, 좋았으면 아래 하단에 광고나 좀 눌러주세요, 코드 깨끗하게 해주시고~
Something else you might like...?
2019/01/16 - [Computer/General] - Path/Location of temporary files in each OS, 운영체제별 임시파일 저장 경로/위치
2019/01/25 - [Life/Health care] - L-Arginine 아르기닌 usage/side effects/dosage 효능/부작용/성인,소아 용법(3)
2019/01/25 - [Life/Health care] - Maca 마카 usage/side effects/dosage 효능/부작용/성인,소아 용법(2)
'Programming > Programming Language' 카테고리의 다른 글
| Comparing Java and Kotlin with pros and cons, 자바와 코틀린 장단점 비교 (0) | 2019.02.20 |
|---|---|
| Scala Advantages & Disadvantages 스칼라 장단점, 객체지향, 함수적, 절차지향적, 프로그래밍언어 (2) | 2018.12.21 |