Ting 이네 Software 이야기

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

__stdcall vs. __cdecl

refer below page..

[[ 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"

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

Requirement is one of most popular cause of problem in software development. Change of requirement always affect overall software development, severely. I want to skip general things about Requirement because there are already lots of stuffs about this. Let's just focus on Requirement of Handset software development. Especially, User Interface Specification (henceforth UIS).

In general, there is department in charge of UIS. The department composes UIS. Then, this UIS is delivered to Development team (development team design software big picture based on this.), designers(designers make images, screen layouts etc based on this), and test team (test team makes test and verification cases based on this.)
As you see, the point is "UIS's impact in the software development is extremely critical.". And usually, number of people who make UIS not alone. And it is true for design, software development and test. Let's image that UIS is not clear. What will happen? In this case - development based on unclear UIS -, huge amount of communication overhead is required between UIS, design, development and test team. This cost is extremely large - over than expected. (I can say like this based on my experience. Believe me.)

Even though clarity of UIS - we can also say it as 'completeness' - is very important, in many cases, it is underestimated. Instead of clarity, originality or creativity of UIS is usually required. I'm not saying that originality and creativity are not important. My point is, clarity or completeness is as important as originality or creativity.

UIS is also a kind of "Specification". So, it should be clear. That's my point.

It is already well known and proved that quality oriented development is better than time oriented development in terms of quality and time.

Time Oriented Development
Developing software with fixed schedule. For example, we should complete this project by 10th of March.
In this case, usually, functionality has priority to show progress. And, quality is put behind. So, software is not tested enough during development. Usually, real stage for test and debugging begins at the latter part of project. This is main cause that make time for test and debugging be longer than expected.

Quality Oriented Development
Development focusing on software quality. Software continuously tested during development to keep software quality good. So, software is debugged at the early stage. So, cost for debugging lessen(It's well known that debugging at the early stage is much cheaper than debugging at the latter stage.). This shorten time and increase quality.

1. Sharing team roaster and contact point.
(members need to know mapping between person and job.)

2. Sharing development environment. (if possible, harmonize environments.)
(Using same development environment can reduce communication overhead dramatically.)

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

[Note: I'm not talking about costs. We can develop something with very low cost for long time.(ex. 1 person for 5 years..)]

Predicting the future is always very difficult. The further is more difficult!
We should predict market situation(the future) when product is released. So, development time means future we should predict. "1-year-development" means "We should predict 1-year-later-future". But, "3-month-development" means just "predicting 3-month-later-future".

Can you understand how important this is?!!!

There is several important reason trying to avoid using global variable. One of them is "Tracking usage is very difficult.". It is extremely difficult for developer to know enough when this variable is used and changed.
It is also true for static variable in C and member variable in C++, JAVA and so on. Let's focus on the case of static variable in C (the case of member variable is also same.).
In simple and short file (ex. less than 500 lines), it's not matter. But, static variable in large-size-file is also difficult to track. Yes, we should keep file small. But in practice, this case is not rare. Whenever we use static variable in large-size-file, we should take care of it. Especially, using flag and state is top of that. In many cases, flag and state are used to branch. So, tracking these values are very important. Let's see following example.

static int _b_ui_mode = FALSE;
static int _operational_mode = IDLE;
funcA ()
{
  ...
  _b_ui_mode = TRUE;
  _operational_mode = USER_INPUT;
}
...
funcP()
{
  if(_operational_mode == IDLE){
    ...
  }
}
...

This is bad example. Assigning value to the static variable directly - especially to the flag and state variable - is the main reason to make tracking software difficlut. At least we should use get()/set() function.; Even in worst case, this makes logging easy. This is minimal requirement to use static variable in large-size-file.

Here ARM example.

BX LR,
LDR PC, XX,
ADD PC, XX, XX

Then, which case can be interpreted to 'indirect branch' in C/C++ - Yes, it's totally dependent on compiler. We just assume general case?

* Return from function call. (BX LR)
* Function call by "function pointer" (LDR PC, XX)
    - using function pointer explicitly.
    - using virtual function pointer table of class.
... anything else???