For code formatting there are several different standards. What is the standard format for Visaul Studio 2010?

How best to separate several functions in the code? sticking in between

/********/

/********/

/********/

or something else?

UPD are all attached to the commenting code and the names of functions / variables. Although the question is different. If this is important to you - all functions are documented by doxygen in the .h file, there is a detailed description of each function. I want to know how I divide the code of these functions in a .cpp file. Not empty lines, by golly.

  • one
    > How best to separate several functions in the code? sticking between them /********/ or something else? There is no need to insert such separators between functions. You just need to comment on what the function does. - insolor
  • > I want to know how to divide the code of these functions in the .cpp file. not empty the same lines, really. Such a question, for what purpose is it divided? - insolor
  • > for what purpose to divide? The job in the course is to issue a code. - Azska
  • As far as I know, there are no such standards that regulate what functions should be separated from each other (and thank God). If someone knows, he can say. - insolor

3 answers 3

We must try to call the functions so that it is clear what they do without comments. If not, then write comments. Each function must do only one action. It is better to separate them with an empty line. It is better to combine functions as intended in different files, rather than mixing everything.

If the editor supports regions, then you can combine several functions into groups by them. For example:

 #pragma region Чтение int GetValue1() { ... } float GetValue2() { ... } #pragma endregion #pragma region Запись void SetValue1(int val) { ... } void SetValue2(float val) { ... } #pragma endregion

In McConnell’s The Perfect Code, all this is there. I advise you to read.

  • About function names and comments. Try and make it two big differences. In reality, this is advice from professors who have broken away from their own programming, whose delusions are all reprinted. In practice, when using long names, the crystal purity of the encoded algorithm is lost. And names like GetValue1 and SetValiue2 in the absence of adequate comments are no more informative than gv1 and sv2. - Briefly repeat. The main thing for the function is a meaningful comment. - avp 2:53 pm
  • > In practice, when using long names, the crystal purity of the encoded algorithm is lost. It is necessary to break the algorithm into small parts. Small functions are unlikely to have a long name. > And names like GetValue1 and SetValiue2 in the absence of adequate comments are no more informative than gv1 and sv2. I did not try to say that they are informative. This was a code showing the regions. > The main thing for the function is a meaningful comment. The function may change and the comment will become obsolete. - gammaker
  • one
    "The function may change, and the comment will become obsolete" - yes, no comments are better than incorrect ones. Similarly, if a function changes, then its name and the names of variables in it may become obsolete. The duty of the programmer to monitor the relevance of comments. - avp pm

Before all non-static (extern) functions, be sure to make comments, moreover, why the function is needed , in what situations it is called. For complex functions, it is good to explain in the comment the motives for writing this function and the environment in which it "lives." What it does and is usually understandable (from the code).

Arrangement of parentheses, padding, spaces around operands - all this is common sense. Usually it is strongly advised to use the same style throughout the program. IMHO to highlight certain semantic code fragments, the style can be changed, but it should be meaningful. For example, try to ensure that the reader intuitively feels that there is a more important piece of code in front of him. Just do not abuse it.

The same principle can be used when naming variables.

    For commenting, it is preferable to use xml comments that are generated after /// , the separation of functions in one empty line. If you want to combine several functions, for example, all public functions, use the regions: #region текст ... #endregion . If your functions are larger than several thousand lines each, you should think about architecture.

    • Oh, I did not notice that the question for the C language ... I do not know about the existence of regions there ... - wind
    • 2
      Regions are created through #pragma region ... #pragma endregion . Unknown pragmas are always ignored by the compiler. Selecting this as separate regions is done by the code editor, not the compiler, so it does not matter which language. - gammaker