좋은 프로그래머의 코드는 어떤 모습일까요? [닫은]
저는 취미 프로그래머 (VBA로 시작하여 더 빨리 엑셀 만들기)이고 VB.NET/C#.NET으로 작업 해 왔으며 ADO.NET을 배우려고합니다.
항상 나를 좌절시키는 프로그래밍의 한 측면은 '좋다'는 것이 어떤 모습일까요? 나는 전문가가 아니므로 비교할 것이 거의 없습니다. 더 나은 프로그래머를 만드는 것은 무엇입니까? 그것은 :
- 주어진 언어의 모든 객체 / 클래스 / 메서드를 더 잘 이해하고 있습니까?
- 그들의 프로그램이 더 효율적입니까?
- 그들의 프로그램 디자인은 더 나은 문서화, 함수 이름의 좋은 선택 등의 측면에서 훨씬 낫습니까?
달리 말하면, 전문 프로그래머의 코드를 살펴보면 나와 관련된 코드에서 가장 먼저 눈에 띄는 것은 무엇입니까? 예를 들어, Wrox press의 'Professional ASP.NET'과 같은 책을 읽었습니다. 그 책의 코드 예제는 '세계적 수준'입니까? 그게 정점입니까? 최고의 프로그래머가 그 코드를보고 좋은 코드라고 생각할까요?
아래 목록은 포괄적이 아니지만 귀하의 질문을 고려할 때 생각한 것입니다.
좋은 코드는 잘 정리되어 있습니다. 클래스의 데이터와 작업은 서로 맞습니다. 클래스간에 외부 종속성이 없습니다. "스파게티"처럼 보이지 않습니다.
좋은 코드 주석은 작업이 수행되지 않은 이유를 설명합니다. 코드 자체는 수행되는 작업을 설명합니다. 의견의 필요성은 최소화되어야합니다.
좋은 코드는 가장 일시적인 개체를 제외한 모든 개체에 대해 의미있는 명명 규칙을 사용합니다. 무언가의 이름은 개체를 언제 어떻게 사용하는지에 대한 정보를 제공합니다.
좋은 코드는 잘 테스트되었습니다. 테스트는 코드의 실행 가능한 사양 및 사용 예제 역할을합니다.
좋은 코드는 "영리한"것이 아닙니다. 간단하고 분명한 방식으로 일을합니다.
좋은 코드는 작고 읽기 쉬운 계산 단위로 개발됩니다. 이러한 단위는 코드 전체에서 재사용됩니다.
아직 읽지 않았지만이 주제에 대해 읽을 예정인 책은 Robert C. Martin의 Clean Code 입니다.
가장 먼저 눈에 띄는 것은 코드가 일관된 코딩 스타일을 따른다는 것 입니다 . 그들은 항상 구조 블록을 동일하게 작성하고 종교적으로 들여 쓰기하고 적절한 곳에 주석을 달습니다.
두 번째로 눈에 띄는 점은 코드가 최대 수십 줄에 이르는 작은 메서드 / 함수로 분할된다는 것입니다. 또한 자체 설명 메서드 이름을 사용하며 일반적으로 코드를 매우 읽기 쉽습니다.
세 번째로, 코드를 약간 엉망으로 만든 후에는 논리를 따르기 쉽고 수정하기 쉬우므로 쉽게 유지 관리 할 수 있습니다.
그 후 소프트웨어 설계 기술에 대한 지식과 경험이 있어야 코드 아키텍처를 구성하는 특정 선택 사항을 이해할 수 있습니다.
책에 관해서는 코드가 "세계적 수준"으로 간주 될 수있는 책을 많이 보지 못했습니다. 책에서 그들은 매우 간단한 문제를 해결하는 데 관련이있을 수 있지만 더 복잡한 상황을 반영하지 않는 간단한 예를 주로 제시하려고합니다.
가독성을 요약 한 Fowler 인용 :
모든 바보는 컴퓨터가 이해할 수있는 코드를 작성할 수 있습니다.
좋은 프로그래머는 인간이 이해할 수있는 코드를 작성합니다.
'아무 말도.
개인적 으로 Tim Peters 의 "The Zen of Python" 을 인용해야합니다 . Python 프로그래머에게 코드가 어떻게 생겼는지 알려주지 만 기본적으로 모든 코드에 적용된다는 것을 알았습니다.
못생긴 것보다 아름다운 것이 낫습니다.
명시적인 것이 암시적인 것보다 낫습니다.
단순한 것이 복잡한 것보다 낫습니다.
복잡한 것이 복잡한 것보다 낫습니다.
플랫이 중첩보다 낫습니다.
희소가 조밀 한 것보다 낫습니다.
가독성이 중요합니다.
특별한 경우는 규칙을 어길만큼 특별하지 않습니다.
실용성이 순결을 능가하지만.
오류는 조용히 전달되지 않아야합니다.
명시 적으로 침묵하지 않는 한.
모호함에도 불구하고 추측하려는 유혹을 거부하십시오.
이를 수행하는 분명한 방법은 하나, 바람직하게는 하나만 있어야합니다.
네덜란드 사람이 아니라면 처음에는 그 방법이 분명하지 않을 수도 있습니다.
지금은 결코하지 않는 것보다 좋습니다.
결코 옳은 것보다 낫지 않지만지금.
구현이 설명하기 어렵다면 그것은 나쁜 생각입니다.
구현이 설명하기 쉽다면 좋은 생각 일 수 있습니다.
네임 스페이스는 멋진 아이디어 중 하나입니다. 더 많은 작업을 수행해 보겠습니다!
코드는시입니다.
이 논리 지점에서 시작하여 원하는 코드의 많은 특성을 도출 할 수 있습니다. 가장 중요한 것은 코드가 작성된 것보다 훨씬 더 많이 읽히므로 독자를위한 코드를 작성하는 것입니다. 독자를 위해 재 작성, 이름 변경, 편집 및 리팩터링하십시오.
추론에 대한 후속 :
독자는 코드 생성 일로부터 n 시간에 당신이 될 것입니다. 독자를위한 코드 작성의 대가는 n의 단조롭게 증가하는 함수입니다. 처음으로 코드를 보는 독자는 n == 무한대로 표시됩니다.
즉, 코드를 작성한 시점에서 코드를 다시 방문 할 때까지의 시간 차이가 클수록 독자를 위해 작성하려는 노력에 더 감사 할 것입니다. 또한 코드를 넘겨주는 사람은 리더가 가장 먼저 고려한 코드로 인해 큰 혜택을 얻을 수 있습니다.
두 번째 결과 :
독자를 고려하지 않고 작성된 코드는 이해하거나 사용하기가 불필요하게 어려울 수 있습니다. 독자에 대한 고려가 특정 임계 값 아래로 떨어지면 독자는 코드를 다시 작성하여 얻은 값보다 코드에서 더 적은 가치를 얻습니다. 이것이 발생하면 이전 코드는 버려지고 비극적으로 재 작성하는 동안 많은 작업이 반복됩니다.
세 번째 결과 :
추론 2는 잘못 문서화 된 코드와 강제 재 작성의 악순환에서 여러 번 반복되는 것으로 알려져 있습니다.
I've been programming for 28 years and I find this a tough question to answer. To me good code is a complete package. The code is cleanly written, with meaningful variable and method names. It has well placed comments that comment the intent of the code and doesn't just regurgitate the code you can already read. The code does what it is supposed to in an efficient manner, without wasting resources. It also has to be written with an eye towards maintainability.
The bottom line though is that it means different things to different people. What I might label as good code someone else might hate. Good code will have some common traits which I think I've identified above.
The best thing you can do is expose yourself to code. Look at other people's code. Open Source projects are a good source for that. You will find good code and bad code. The more you look at it, the better you will recognize what you determine to be good code and bad code.
Ultimately you will be your own judge. When you find styles and techniques you like adopt them, over time you will come up with your own style and that will change over time. There is no person on here that can wave a wand and say what is good and that anything else is bad.
Read the book Code Complete. This explains a lot of ideas about how to structure code and the the reasons for doing so. Reading it should short-circuit your time to aquiring the experience necessary to tell good from bad.
Having been programming for nearly 10 years now myself and having worked with others I can say without bias that there is no difference between a good programmer and an average programmers code
All programmers at a competent level:
- Comment Correctly
- Structure Efficiently
- Document Cleanly
I once overheard a co-worker say "I've always been very logical and rational minded. I think that's why I enjoy developing"
That in my opinion, is the mind of an average programmer. One who sees the world in terms of rules and logic and ultimately obeys those rules when designing and writing a program.
The expert programmer, understands the rules, but also their context. This ultimately leads to them coming up with new ideas and implementations, the mark of an expert programmer. Programming is ultimately an art form.
Succinctly put, a good programmer's code can be read and understood.
In my opinion, a good programmer's code is language-agnostic; well-written code can be read and understood in a short amount of time with minimal thinking, regardless of the programming language used. Whether the code is in Java, Python, C++ or Haskell, well-written code is understandable by people who don't even program in that particular language.
Some characteristics of code that is easy to read are, methods that are well-named, absence of "tricks" and convoluted "optimization", classes are well-designed, to name a few. As others have mentioned, coding style is consistent, succinct and straight-forward.
For example, the other day, I was taking a look at the code for TinyMCE to answer one of the questions on Stack Overflow. It is written in JavaScript, a language that I've hardly used. Yet, because of the coding style and the comments that are included, along with the structuring of the code itself, it was fairly understandable, and I was able to navigate through the code in a few minutes.
One book that was quite an eye-opener for me in the regard of reading good programmer's code is Beautiful Code. It has many articles written by authors of various programming projects in various programming languages. Yet, when I read it, I could understand what the author was writing in his code despite the fact that I've never even programmed in that particular language.
Perhaps what we should keep in mind is that programming is also about communication, not only to the computer but to people, so good programmer's code is almost like a well-written book, which can communicate to the reader about the ideas it wants to convey.
- Easy to read
- easy to write
- easy to maintain
everything else is filigree
Good code should be easily understood.
It should be well commented.
Difficult parts should be even better commented.
Good code is readable. You'd have no trouble understanding what the code is doing on the first read through of code written by a good professional programmer.
Just wanted to add my 2 cents... comments in your code -- and your code itself, generally -- should say what your code does, now how it does it. Once you have the concept of 'client' code, which is code that calls other code (simplest example is code that calls a method), you should always be most worried about making your code comprehensible from the "client's" perspective. As your code grows, you'll see that this is... uh, good.
A lot of the other stuff about good code is about the mental leaps that you'll make (definitely, if you pay attention)... 99% of them have to do with doing a bit more work now to spare you a ton of work later, and reusability. And also with doing things right: I almost always want to run the other way rather than using regular expressions, but every time I get into them, I see why everybody uses them in every single language I work in (they're abstruse, but work and probably couldn't be better).
Regarding whether to look at books, I would say definitely not in my experience. Look at APIs and frameworks and code conventions and other people's code and use your own instincts, and try to understand why stuff is the way it is and what the implications of things are. The thing that code in books almost never does is plan for the unplanned, which is what error checking is all about. This only pays off when somebody sends you an email and says, "I got error 321" instead of "hey, the app is broke, yo."
Good code is written with the future in mind, both from the programmer's perspective and the user's perspective.
Rather then repeat everyone else's great suggestions, I will instead suggest that you read the book Code Complete by Steve McConnell
Essentially it is a book packed full of programming best practices for both functionality and style.
[Purely subjective answer]
For me, good code is a form of art, just like a painting. I might go further and say that it's actually a drawing that includes characters, colors, "form" or "structure" of code, and with all this being so readable/performant. The combination of readability, structure (i.e. columns, indentation, even variable names of the same length!), color (class names, variable names, comments, etc.) all make what I like to see as a "beautiful" picture that can make me either very proud or very detestful of my own code.
(As said before, very subjective answer. Sorry for my English.)
I second the recommendation of Bob Martin's "Clean Code".
"Beautiful Code" was highly acclaimed a couple of years ago.
Any of McConnell's books are worth reading.
Perhaps "The Pragmatic Programmer" would be helpful, too.
%
This is answered pretty well in Fowler's book, "Refactoring", It's the absence of all the "smells" he describes throughout the book.
I haven't seen 'Professional ASP.NET', but I'd be surprised if it's better than OK. See this question for some books with really good code. (It varies, of course, but the accepted answer there is hard to beat.)
This seems to be (should be) a FAQ. There is an ACM article about beautiful code recently. There seems to be a lot of emphasis on easy to read/understand. I'd qualifier this with "easy to read/understand by domain experts". Really good programmers tend to use the best algorithms (instead of naive easy to understand O(n^2) algorithms) for any given problems, which could be hard to follow, if you're not familiar with the algorithm, even if the good programmer gives a reference to the algorithm.
Nobody is perfect including good programmers but their code tend to strive for:
- Correctness and efficiency with proven algorithms (instead of naive and adhoc hacks)
- Clarity (comment for intent with reference to non-trivial algorithms)
- Completeness to cover the basics (coding convention, versioning, documentation, unit tests etc.)
- Succinctness (DRY)
- Robustness (resilient to arbitrary input and disruption of change requests)
i second the recommendation for uncle bob's "clean code". but you may wish to take a look at http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 as i think this deals with your specific question a bit better. good code should leap off the page and tell you what it does/how it works.
Jeff Atwood wrote a nice article about how coders are Typists first reference: http://www.codinghorror.com/blog/archives/001188.html
When being a typist you always need to be elegant in your work, having strucutre and proper "grammar" is highly important. Now converting this to "programming"-typing would catch the same outcome.
Structure
Comments
Regions
I'm a software engineere which means during my education i've come across many different languages but my programming always "feel" the same, as my writing does on fekberg.wordpress.com, i have a "special" way for typing.
Now programming different applications and in different languages, such as Java, C#, Assembler, C++,C i've come to the "standard" of writing that i like.
I see everything as "boxes" or regions and each region has it's explaining commenting. A region might be "class Person" and inside this Region i have a couple of methods for properties, which i may call "Access Methods" or such and each property and region has it's own explaining commenting.
This is highly important, i always see my code that i do, as "being a part of an api", when creating an API structure and elegance is VERY important.
Think about this. Also read my paper on Communication issues when adapting outsourcing which explains in rough, how bad code can conflict, Enterpret as you like: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/
Good code is easy to understand, easy to maintain, and easy to add to. Ideally, it is also as efficient as possible without sacrificing other indicators.
Great code to me is something that is simple to grasp yet sophisticated. The things that make you go, "wow, of course, why didn't I think of it that way?". Really good code is not hard to understand, it simply solves the problem at hand in a straight-forward way (or a recursive way, if that is even simpler).
Good code is where you know what the method does from the name. Bad code is where you have to work out what the code does, to make sense of the name.
Good code is where if you read it, you can understand what it's doing in not much more time than it takes to read it. Bad code is where you end up looking at it for ages trying to work out wtf it does.
Good code has things named in such a way as to make trivial comments unnecessary.
Good code tends to be short.
Good code can be reused to do what it does anywhere else, since it doesn't rely on stuff that is really unrelated to its purpose.
Good code is usually a set of simple tools to do simple jobs (put together in well organised ways to do more sophisticated jobs). Bad code tends to be huge multi-purpose tools that are easy to break and difficult to use.
Code is a reflection of a programmer's skills and mindset. Good programmers always have an eye on the future - how the code will function when requirements or circumstances are not exactly what they are today. How scalabale it will be? How convenient it will be when I am not the one maintaining this code? How reusable the code will be, so that someone else doing similar stuff can reuse the code and not write it again. What when someone else is trying to understand the code that I have written.
When a programmer has that mindset, all the other stuff falls in place nicely.
Note: A code base is worked on by many programmers over time and typically there is not a specific designation of code base to a programmer. Hence good code is a reflection of all the company's standards and quality of their workforce.
(I use "he" below because this is the person that I aspire to be, sometimes with success).
I believe that the core of a good programmer's philosophy is that he is always thinking "I am coding for myself in the future when I will have forgotten all about this task, why I was working on it, what were the risks and even how this code was supposed to work."
As such, his code has to:
- Work (it doesn't matter how fast code gets to the wrong answer. There's no partial credit in the real world).
- Explain how he knows that this code works. This is a combination of documentation (javadoc is my tool of choice), exception handling and test code. In a very real sense, I believe that, line for line, test code is more valuable than functional code if for no other reason than it explains "this code works, this is how it should be used, and this is why I should get paid."
- Be maintained. Dead code is a nightmare. Legacy code maintenance is a chore but it has to be done (and remember, it's "legacy" the moment that it leaves your desk).
On the other hand, I believe that the good programmer should never do these things:
- Obsess over formatting. There are plenty of IDEs, editors and pretty-printers that can format code to exactly the standard or personal preference that you feel is appropriate. I use Netbeans, I set up the format options once and hit alt-shift-F every now and then. Decide how you want the code to look, set up your environment and let the tool do the grunt work.
- Obsess over naming conventions at the expense of human communication. If a naming convention is leading you down the road of naming your classes "IElephantProviderSupportAbstractManagerSupport" rather than "Zookeeper", change the standard before you make it harder for the next person.
- Forget that he works as a team with actual human beings.
- Forget that the primary source of coding errors is sitting at his keyboard right now. If there's a mistake or an error, he should look to himself first.
- Forget that what goes around comes around. Any work that he does now to make his code more accessible to future readers will almost certainly benefit him directly (because who's going to be the first person asked to look at his code? He is).
- It works
- It has unit tests that prove that it works
The rest is icing...
- The best code has a certain elegance that you recognise as soon as you see it.
- It looks crafted, with care and attention to detail. It's obviously produced with someone with skill and has an art about it - you could say it looks sculpted and polished, rather than rough and ready.
- It's consistent and reads easily.
- It's split into small, highly cohesive functions each of which do one thing and do it well.
- It's minimally coupled, meaning that dependencies are few and strictly controlled, usually by...
- Functions and classes have dependencies on abstractions rather than implementations.
Ironically the better the programmer the less indispensable he/she becomes because the code produced is better maintainable by anyone (as stated by general consent by Eran Galperin).
My experience tells the opposite is also true. The worse the programmer the more difficult to maintain his/her code is, so more indispensable he/she becomes, since no other soul can understand the riddles produced.
I have a good example :
Read GWT (google web tookit) Source code, you will see that every fool understand it (some english books are harder to read than this code).
참고URL : https://stackoverflow.com/questions/366588/what-does-a-good-programmers-code-look-like
'developer tip' 카테고리의 다른 글
| CONDITIONS가있는 COUNT DISTINCT (0) | 2020.09.11 |
|---|---|
| jQuery는 AJAX 쿼리에서 내 JSON을 구문 분석하지 않습니다. (0) | 2020.09.11 |
| EditText의 setHintTextColor () (0) | 2020.09.10 |
| Java에서 날짜가 두 날짜 사이에 있는지 어떻게 확인할 수 있습니까? (0) | 2020.09.10 |
| Java를 사용하여 16 진수를 RGB로 변환하는 방법은 무엇입니까? (0) | 2020.09.10 |