나쁜 코드의 10가지 징후 10 SIGNS OF REALLY BAD CODE

좋은 글들은 영문으로 많다. 코딩이든, 달리기, 마라톤이든 거의 모든 분야가 그렇다. 번역은 구글 번역을 돌리지만 형편없다. 집중해서 번역해야 하는데 마음이 가지 않는다. 일단은 올리고 뒤도 안보고 도망친다.

나쁜 코드의 10가지 징후 

1. 댓글 코딩은 죄입니다

나는 이것을 똑바로합시다. 풍부하고 잘 작동하는 소스 코드를 본 적이 있습니다 만, 코멘트는 사용되지 않지만 코드를 읽을 시간이 없습니다. 내 마음에 오는 첫번째 것은 "Bad Code"입니다. 개발하는 응용 프로그램은 항상 당신 만이 관리 할 수있는 것은 없습니다. 응용 프로그램이 늘고 유지 보수가 필요할 때 동일한 코드를 사용하여 작업 할 필요가 증가합니다. 그리고 나에게 말해. 새로운 프로그래머는 코드를 이해하는데 정말 오랜 시간이 걸립니다. 기회는 당신의 코드를 편안하게하기 위해 코드를 변경해야 결국 전체 프로젝트가 어색 복잡하게 될 수 있습니다.

이 글을 쓰는 동안 나는 다른 시나리오를 실현했습니다. 당신이 프로그램에서 어떤 함수를 사용한 이유 또는 함수의 적어도 일부 라인을 기억하지 못하는 상황에 있었다고 믿습니다. 나는 당신이 이것을 부정 할 수 없다는 것을 알고 있습니다 (당신이 코멘트를 사용하지 않은 경우). 그러면 실제로 모두 분석하여 실제로 사용 된 논리를 알아낼 때까지 다른 프로그래머가 당신의 코드를 쉽게 이해할 수있게하려면 어떻게해야합니까? 코드가 본문의 경우, 주석은 코드가 둘 의류입니다. 코드에서 주석을 사용하는 것에 대하여 더 많은 것을 말할 수 있습니다. 댓글만을위한 별도의 문서를 사용합니다.

2. 버그를 수정하면 새로운 버그가 생성되는

이것은 모든 프로그래머가 버그 나 적어도 주요 것을 제외하고 신청서를 작성하기 전에 적어도 몇 번은 통과해야하는 가장 일반적인 단계 중 하나입니다. 이러한 문제의 주요 원인은 어떤 코드를 일반화 특정 목적에 한정 할 것인가를 결정할 수없는 것입니다. 또 다른 이유는 너무 많은 하드 코딩을 사용하여 기능간에 적절한 체인 / 네트워크를 구축 할 수없는 것입니다.

이것을 피하기 가장 좋은 방법은 처음부터 의식하고 코드가 제대로 정리 된 계층 구조가 유지되도록하는 것입니다.

3. 코드는 재사용 불가능합니다

이는 유사한 기능이 관련된 경우 응용 프로그램 코드의 일부를 다른 프로젝트에서 사용할 수없는 일반적인 시나리오입니다. 일반화 된 코드를 작성하는 것은 모든 응용 프로그램에서 비슷한 기능을 사용해야합니다. 이 방법은 코드를 재사용 할 수있을뿐만 아니라 다른 시간이 걸리는 작업에 소요되는 시간을 절약 할 수 있습니다. 그리고 이것은 모든 측면에서 논리 / 알고리즘을 분석하는 데서 오는뿐입니다. 거의 같은 동작을 할 수있는 응용 프로그램의 기능이 부족하지 않은 것을 확인하지만 코드는 별도로 설명되어 있습니다.

재사용 가능한 코드가 없으면 간접적으로 코드 중복이 발생합니다. 그리고 시간이 지남에 코드가 필요하다는 것을 인식조차 못하고 결국 전체 프로젝트가 서투른되고 유지 보수가 어려워집니다.

4. 다른 프로그래머가 코드를 이해할 수 없다

사용자 / 고객 친화적 인 응용 프로그램을 구축 할 하나입니다. 또한 응용 프로그램 프로그래머에게도 친화적임을 확인하는 것도 매우 중요합니다. 결국 응용 프로그램이 커지고, 그것을 유지하기 위해 두 개의 손이 필요할 수 있습니다. 응용 프로그램을 유지하는 데 도움이 두 번째 프로그래머는 코드를 볼 때 코드를 이해할 필요가 있습니다. 대부분의 경우 이미 작성된 코드를 생각하고 분석하고 이해하는 데 몇 시간을 보낼 수 있습니다. 버그를 수정해야 기존 코드를 수정하는 것이 아니라 새 코드 블록을 작성해야 할 수 있습니다. 결국 이로 인해 코드의 중복도 생깁니다. 그리고 이것은 버그를 수정하여 새로운 버그가 발생하는 이유 중 하나 프로그래머가 완벽하게 작동하는 코드를 변경하는 방법 블록의 코드가 어떤 기능을 트리거하는지 아무도 모른다 때문입니다 . 공짜! 기타 버그.

5. 필요한 코드 행을 손쉽게 찾을 수 없다

프로그래머가 원하는 코드의 정확한 행을 찾을 수없는 경우 이전 코드에 수정을 할 것이 아니라 다른 줄을 쓸 수 있습니다. 이것은 나쁜 코드의 증상 중 하나이며, 코드 중복의 원인 중 하나입니다. 지금까지 코드의 중복이 다른 나쁜 코드의 현상에 관여하고있는 것으로 나타났습니다지도 모릅니다. 요점에 돌아 오면 코드를 찾을 수없는 가장 큰 이유는 코멘트를 사용하지 않는 것입니다. 이 상황은 나쁜 코드 (4 1) 다른 징후와 관련 있기 때문에 나는 다시 시나리오를 설명 할 필요는 없다고 생각한다.

6. 기능에 따라 이름이 지정되지 않은

변수 이름이나 함수 파일 등의 이름을 넣을 수없는 경우에는 "프로그래밍 언어의 학습을하지 마십시오. 먼저 코딩 표준을 배우고 배워 봅시다. 나는 당신을 고려할지도 모릅니다. 그리고 이것은 코드가 이해하지 못하게합니다. 또한 시간이 지남에 자신의 코드를 찾을 수 없습니다.

누군가의 코드를보고, resp과 "ANS"와 res를 읽고있는 변수를 많이 사용했지만 어떤 응답, 응답 결과를 이해하지 못합니까? 나는 그것이 일어난 위치로 돌아 이전 프로그래머의 의도를 찾기 위해 코드를 추적해야했습니다. 불행히도,이 코드를 지금부터 유지해야합니다. 일전에, 나는 "meminable code, leave company"하지만 난 아직 그 나쁜 코드에서 뭔가 좋은 것을 가지고 싶어했기 때문에 코드 구조를 배우고 코드를 써야 아니라는 것을 배웠습니다.

7. 파일과 폴더가 분리 / 분류되지 않은

응용 프로그램이 크기를 늘려 특정 코드를 찾아 계속 또 다른 이유는 코드가 제대로 정리되지 않은 것입니다. 누군가가 코드를 보면 함수의 소재를 많은 투쟁.

8. 응용 프로그램이 복잡

응용 프로그램이 너무 복잡 느낀다면, 이것은 나쁜 코드입니다. 지금까지 언급 한 나쁜 코드의 다른 모든 증상이 같은 점이 반복되는 것을 모르고 있을지도 모릅니다. 만약 당신이 이것을 수정하면 실제로는 다른 프로그래밍 죄를 수정하거나 적어도 당신은 다른 사람을 수정할 필요가 없기 때문입니다.

9. 글로벌을 사용하지

당신은 어떤 텍스트와 다른 값을 여러 장소에서 사용하고 있었지만, 어디 값을 변경해야한다 날이 올 것입니다. 이러한 파일을 수동으로 열고 어디서나 값을 변경하면 당신이 전역 변수를 선언하는 경우 필요한 경우 어디서나 사용할 수 있습니까? 글로벌 변수의 값을 한 번 변경하면, 같은 일을 할 수 있습니다.

10. 당신은 종종 프로젝트 전체를 다시 작성하도록 자극

정말 정말 정말 정말 모든 기준을 정확하게 수행하고 프로세스의 모든 격차를 해소하여 전체 응용 프로그램을 다시 작성하려면 이렇게 느낀다면 먼저 진행합니다.

글쎄, 이들은 정말 나쁜 코드에서 찾을 수있는 주요 증상 중 일부입니다. 다른 많은 것들을 찾을 수 있지만, 지금까지 말한 일이 일어나지 않았는지 확인하면 코드를 쉽게 유지 보수 할 수 있습니다. 더 흥미로운 것이 있습니다! 그때까지 당신은 흔들리고 있습니다!

원문출처와 아래는 원문 : http://developerbhanu.com/blog/bad-code-symptoms

10 SIGNS OF REALLY BAD CODE

1. Coding Without Comments is a Sin

Let me put this straight. If I ever happen to see someone's source code that's feature rich and fully working, but no comments are used, I won't even take time to read the code. The first thing that comes to my mind is 'Bad Code'. You always have to remember that the application you're developing cannot always be maintained only by you. As the application grows and maintenance becomes necessary, you'll need some more hands working on the same code. And let me tell you this, the new programmer takes a really long time to understand the code. Chances are, they may also have to change your code to make it comfortable for them, and eventually the whole project becomes clumsy and complicated.

While writing this, I realized some other scenario. I believe you've been in situations where you cannot remember why you used some functions in your program or at least few lines in the function. I know you can't say no to this (if you didn't use comments). So how can you expect other programmers understand your code easily unless they really analyze it all in their head and then come up with the actual logic you've used? If the code is the body, then comments are the apparel the code puts on. There is so much more I can tell you about using comments in a code, maybe I'll use another article just for comments.

2. Fixing a Bug Creates New Bugs

This is one of the most common stages every programmer has to go through at least a few times before completing the application without any bugs, or at least major ones. The main cause of such an issue is not being able to decide what code should be generalized and what should be restricted to a specific purpose. And another reason is using too much hard coding and not being able to construct a proper chain/network among functionalities.

The best way to avoid this is by being conscious from the beginning and making sure the code is correctly organized and hierarchy is maintained as it should. 

3. The Code is Not Reusable

This is a common scenario where you cannot use any part of your application's code in another project when similar functionalities are involved. Writing generalized code, that can be used for any similar functionality across all applications is necessary. This practice not only makes code reusable, it can also save you a whole lot of time to work on other, time-consuming tasks. And this can only come from analyzing the logic/algorithm from all sides. Just make sure you're not missing any functionality in the app that can have almost similar behavior but the code is written separately.

The absence of reusable code indirectly causes code redundancy. And as time goes by, you can't even recognize what code is unnecessary and eventually the whole project becomes clumsy and hard to maintain.

4. Other Programmers Cannot Understand The Code

It is one thing to build the application that is user/customer friendly. And it is also very important to make sure the application is also programmer friendly. Eventually, the application gets bigger and you may have to need two more hands to maintain it. The second programmer who helps you maintain the application needs to understand the code when he looks at it. Most of the time, he/she may spend hours to think, analyze and understand the code that is already written. Chances are, the bugs need to be fixed fast, and they may sometimes have to write a new block of code instead of fixing the old code. Eventually, this will also lead to code redundancy. And this is one of the reasons why fixing a bug creates a new bug because no one knows which block of code triggers which functionality, so the programmer changes the fully working code. Tada! More Bugs.

5. You Cannot Find Required Line of Code Easily

Not being able to find the exact line of code that a programmer is looking for makes him/her write another line instead of adding tweaks to the old code. This is one of the symptoms of bad code, and also one of the causes of code redundancy. By now, you may have noticed that code redundancy is also involved in the other bad code symptoms. Coming back to the point, the primary reason for not finding the code is not using comments. As this situation is related to the other signs of bad code (4 and 1), I don't think I have to explain the scenario again.

6. Things Are Not Named According To The Functionality

Ah! Good old naming conventions. What can I say? If you're not able to name the variables, functions, files or whatever, I will just tell you one thing, "Stop learning programming languages. First, learn coding standards and come back. And then I may consider you." And again, this makes the code not understandable, and also makes you not find your own code over time.

I still cannot understand what makes it so hard to name things. I saw someone's code and they were using a lot of variables that read resp or 'ANS' or res. And I don't understand what kind of response, answer or result it is. I had to go back to where it was triggered and trace the code to find the previous programmer's intention. And unfortunately, I have to maintain that code from now. The other day I saw a meme that reads, "Writes unmaintainable code, leaves company." But I still wanted to take something good out of that bad code, so I studied the code structure and learned how a code should not be written.

7. Files and Folders Are Not Separated/Categorized

Another reason why your application keeps increasing in size and finding a specific code is a headache is not organizing your code properly. You have to make sure, if someone else looks at the code, he should be able to tell the whereabouts of functions without a lot of struggle.

8. The Application Gets Complicated Overtime

If you feel like the application is too complex to work on, that's a bad code. You may have already noticed this same point repeating in all the other signs of bad code I've mentioned so far. I had to mention this a separate sign because if you fix this, you actually fix all the other programming sins in the process. Or at least you don't have to fix the others.

9. Not Using Globals

You used some text or any other values in several places, and there comes a day when you have to change the value everywhere. Now if you're manually opening those files and changing the value everywhere, your code is counted as 'bad code'. What if you declared a global variable, and just use it wherever needed? Changing the value of the global only once does the same job for you.

10. You Are Often Tempted To Rewrite The Whole Project

There comes a day when you really, really want to rewrite the whole application by following all the standards correctly and filling all gaps in the process. If you feel like doing this, please do go ahead. Just make sure you can afford it though.

Well. these are some of the main symptoms we can find in a really bad code. You can find many others but if you make sure if these things mentioned so far don't happen, your code can be easily maintainable. I'll come back with some more exciting stuff! Until then, you keep rocking!