[Reading notes] code neat Way (iii)

Continue the Book of reading notes of the collation. Fifth Chapter Format

This chapter focuses on some of the code layout recommendations, of course, these are only suggestions, after all, the code format of the things that each company and even different teams may be different.
The format of the code is the style of the code, which is closely related to the clarity of the code and how readable the code is, depending largely on the clarity of the code.
You can see the format of the code from the horizontal and vertical two directions of the code. Landscape Format

The most obvious is the indentation of the code, which can visually layer the code, for example:

if (A)
{
    ...
    if (B)
    {
        ...
        ...
    }
    ...
}
else
{
    ...
    ...
}

You can clearly see the different levels of conditional statement blocks, which need to pay attention to the use of the TAB key , if your code may run on multiple platforms, then pay special attention to the TAB key on different platforms the actual distance of the code may not be the same, so, A more general approach is to map the TAB key to a specific number of spaces (typically 4 spaces), while spaces are common across platforms, and most of the Ides will provide this mapping capability.
The other is the use of spaces, such as the assignment of an equal sign before and after a space, parameters and parameters of the space between, and so on, these normative things in specific coding specifications of the project are often referenced. portrait Format

The vertical format refers to the code's top-down distribution style, which can be thought of as the direction of the overall flow of the code, so it is best to have a self-inflicted relationship between functions in the called function, for example:

void Funca ()
{
    funcb ();
}

void Funcb ()
{
    FUNCC ();
}

void FUNCC ()
{
    funcd ();
}

....

This is a format that matches the flow of code, or the code reading order, and when other people are reading your code, you can read the entire code from top to bottom, rather than if the code looks like this:

void FUNCC ()
{
    funcd ();
}

void Funcb ()
{
    FUNCC ();
}

void Funca ()
{
    funcb ();
}

....

It is easy to compare the differences.
The Code portrait format reflects the closeness of the code in the vertical direction, so the declaration of the variable should be close to where it is used, the function that has the call relationship should be together, and the concept-related code will be put together, which will help to improve the readability of the code. Finally, follow the team rules

The above is only some Fan Xiang of the reference Code, the final implementation of the specific project, the primary reference is of course the book team's rules, if the law is inappropriate or can improve the rules, then team members can negotiate together for the entire team to write high-readability code and efforts. sixth chapter objects and data Structures

This chapter explores the differences between pure data structures (such as structs) and object-oriented (such as C + +) in process-oriented processes (such as C) to guide the situations in which they should be used.
Procedural code facilitates the addition of new functions without altering the existing data structures, and the object-oriented code facilitates the addition of new classes without altering the existing functions. In turn, process-oriented code is difficult to add new data structures because all functions must be modified, and object-oriented code is difficult to add new functions because all classes must be modified.
In summary, objects expose behavior, hide data, and make it easy to add new object types without modifying existing behaviors and, of course, adding new behaviors to existing objects. Data structures are exposed, with no obvious behavior, to add new behaviors to existing data structures, and to add new data structures to existing functions.
When the system needs to be flexible in adding new data types, this section is suitable for working with objects, and when you want to add new behaviors flexibly, this section is suitable for working with data types and procedures. Seventh chapter error handling

Error handling is unavoidable in the code and can greatly increase the number of code-adjustable things, this chapter gives a few reference guidelines, in order to better provide the error itself and error context information when the program goes wrong.
1. Use exceptions rather than error codes. Of course, this depends on the language itself for the exception of the support situation, otherwise it may be necessary for developers to build their own wheels. The error code is not good enough because it messes up the caller code, and the caller must check all possible error codes immediately after the call, for example:

Handle Handle = handler. GetHandle ();
if (INVALID = = handle)
{...//what to does when
    INVALID handle
}
else if (Big_handle = = handle)
{
    ...
}

On the contrary, the way to directly throw an exception is more intelligent, the code is concise enough, logic is good enough.
2. Write the Try-catch statement first. This benefit is like a code architecture design, first of all, the code to run the possible normal-error structure, but also easy to step-by-single test.
3. Using an uncontrolled exception, this in C + + is not to specify the specific type of exception that might be thrown (exception specification), because if a new exception type is added later, all the catch statements inside and out need to be modified, and once there are omissions, The corresponding exception is likely not to be captured by the upper layer (the compiler seems to have such a check now).
4. Give an indication of the circumstances in which the exception occurred. It is more common to call stack information to facilitate locating the context of the code when the exception occurs.
5. Define the general process, this is to say do not let the exception code break the business logic, for example:

Try
{
    mealexpense expenses = expenseproxy.getmeals (employee. GetId ())
    m_total + = expenses. Gettotal ();
}
catch (Exceptionnotfound)
{
    M_total + = Getcommonmealexpense ();
}

The

exception becomes part of the actual business logic, which is unreasonable, and a better practice is to create a class that handles this special case (spacial cases pattern).
6. Do not return a null value because returning a null value means that all code needs to check for a null value after calling code that might return a null value, otherwise an error may occur without knowing it. Instead, use a Terry object code for these null cases.
7. Disable the passing of NULL values because unexpected NULL is difficult to handle unless the API has a clear description that could pass in null values, such as many of the functions provided by the Windows platform itself will be the default values for the null parameter value group.
The main idea in this chapter is that it can be handled separately and greatly improve the maintainability of code by not treating it as an isolated view, independent of the main business logic.