[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

Followings are all my personal opinion!

We always tell "good code". And lots of constraints are suggested for so-called "good code". For example, "number of line in one function should be less than xx", "number of class members should be less than xx", and so on.

Let's think from the basic. What is "good code". We don't need messy conditions for this. Just one factor!.
I want to define "good code" as "code that is easy-to-understand". Codes that is easy-to-understand, are easy to modify too.

Let's talk about this more.
"code that is easy-to-undertand" means, "It should be easy to know that the codes for and to predict the execution result.". Then what we should do to acheive this?

"Making code be small" can be an option. Anyway, small codes are easy. But, without reducing features and functionalities, decreasing code size enough is impossible. So, in practice, the is not a solution.

Let's convert the sentence into "Making stuffs required to be understood, be small". How about this? We can use lots of reliable module/component to do this. For example, let's think about standard library. We don't try to understand inside of each standard library functions because, we already trust the library enough. So, after understand inputs and outputs, we just use it. If we should understand inside of all those library functions, it will be nightmare. Too many things to understand!

In this context, we can say OOP(Object Oriented Programming), component-based software engineering, modularity, and so on. Making reliable and reusable modules/components can reduce stuffs required to be understood. Knowing input and output is much simpler than understanding inside codes of it.

This is my definition about "good code"

+ Recent posts