Location>code7788 >text

AstralNahida's code style

Popularity：450 ℃/2025-04-26 15:27:30

Preface

Here is a detailed introduction to the code wind of Konjac OIer AstralNahida in OI.
I personally think the code style is quite clear, for your reference.

Agree

For some keywords that express necessity,mustarrivemustn'tThe sort is as follows:

Must > try > should > suggest > can > not recommend > should not > try not > should not.

For the convenience of reading, all the above keywords in this article are usedBold textexpress.

Also, if not"At least", "at most"The limitation of equal words, all numbers areStrict。
For example, in "There is a blank line in the middle", "There is one" by default"There is only one"。

Part 1 · Overall

Here is a copy I made for LuoguP2078Code:

#include <iostream>
#include <map>

#define upFor(i, a, b) for (int i = a; i <= b; i++)

#define Nahida return 0

std::map<int, int> pa;

int findRt(int x) {
    return x == pa[x] ? x : pa[x] = findRt(pa[x]);
}
void merge(int x, int y) {
    pa[findRt(x)] = findRt(y);
}
bool haveSameRt(int x, int y) {
    return findRt(x) == findRt(y);
}

int main(void) {
    int aVtxNum, bVtxNum, aEdNum, bEdNum;
	std::cin >> aVtxNum >> bVtxNum >> aEdNum >> bEdNum;
	upFor (i, -bVtxNum, aVtxNum) pa[i] = i;
	upFor (i, 1, aEdNum + bEdNum) {
		int u, v;
		std::cin >> u >> v;
		merge(u, v);
	}

	int ansA = 0, ansB = 0;
    upFor (i, 1, aVtxNum)
		if (haveSameRt(pa[i], 1)) ansA++;
	upFor (i, -bVtxNum, -1)
		if (haveSameRt(pa[i], -1)) ansB++;

	std::cout << std::min(ansA, ansB) << '\n';

	Nahida;
}

It's probably like this.
From this we can see that my code is roughly divided into four parts:

  1. #includepart, used to include the header file required by the code;
  2. #definePart, used to make some simplified code macro definitions and some of your own little habits (such as Line 6's#define Nahida return 0）；
  3. Declaration and definition parts of global variables, constants and functions;
  4. Main function part.

This piece only provides the overall view of the code. See below for details on the specific rules of the code style.

Part 2 · Header file including and macro definition

Chapter 1 · Header File

For any project, when writing codeNoUse universal head<bits/stdc++.h>. Except for the time you can take less time when you are practicing the questions, the rest are all disadvantages.

For referenced header files, C standard header filesshouldUse tocprefixed form, not.his the form of the suffix.
For example,<> shouldWritten<cstring>。

For all header files,suggestionPut the C standard header files together, thenmustFollow a blank line and include the C++ header file.
In addition,suggestionClassify the included header files as the function of the header file, in the middle of each categorymustSplit by a blank line.
Choose one of the two segmentation methods above.

in addition,Nouseusing namespace std;, otherwise the function name and variable name are prone to conflict.
If necessary,Canuseusing std::sort;This method still needs to be sure that there is no conflict between function names and variable names.

Chapter 2 Macro definition

For any macro definition, its function is any of the following two types: 1° simplify the code or define constants; 2° satisfy your own small habits.
If these two macro definitions appear in a copy of code, you need to put the two macro definitions together in the middlemustSeparated by a blank line.

Part 3 · Indentation and Braces

Chapter 1 · Indentation

indentationmustUse 2 space indentation or 4 space indentation, butNoMixed use.
Inside each brace orcase、public、privateInside,mustUse one portion of indent.
For very long expressions, branches are needed to ensure readability and maintainability.mustUse one portion of indent.
Any#Before the beginning of the instructionNoUse indentation, whether it is inside a block that originally required to use indentation.

Chapter 2 · Braces

There are two common styles of braces:

  • "Transparent" style:
if (1 + 1 == 2)
{
    break;
}
  • "Full" style:
if (1 + 1 == 2) {
    break;
}

mustUse either of these two, andNoMixed use.
More heresuggestionUse the second type, otherwise if there are few internal statements, the entire code will feel more empty.

Part 4 · Spaces and empty lines

Chapter 1 · Spaces

mustMake proper use of spaces, otherwise the code will be too compact (to put it bluntly, squeeze into a lump), affecting the visual sense, readability and maintainability.

The locations listed belowmustUse a space:

  • The left and right sides of the binocular operator (specially,+and-When used as a positive sign, between the following expressionNouse spaces);
  • left and right sides of the flow operator;
  • ifseries,whileanddo-while、switch、forandforeachBetween etc. and the subsequent (or leading) braces or brackets;
  • When a pair of braces are on the same line, after the left braces and before the closing braces;
  • In the three-point operator,?and:left and right sides;
  • *When denoting the pointer type, if followed by the variable name, it is between the variable name;
  • #includeWith the back<>between;
  • When using "full" style braces, between the left braces and the leading content;
  • ,or;Between the following expression;
  • othermustWhere to use spaces.

anyExcept as indentationPlace, allNoThere are several spaces in conjunction.

The locations listed belowNoUse spaces:

  • ::、->、.left and right sides;
  • *When representing the content referenced by the pointer, it is between the following variable name;
  • *When denoting a pointer type, between the leading type name;
  • Between the function name and the parentheses;
  • ,or;to the left;
  • Between the monolog operator and the expression participating in the operation;
  • +and-When used as a sign, it is between the expression followed by;
  • otherNoWhere to use spaces.

Chapter 2 · Blank

mustProperly use blank lines, otherwise the code will be too compact (to put it bluntly, squeeze into a lump), affecting the visual sense, readability and maintainability.

It is mentioned in the first part that the code is roughly divided into four parts, with each part being betweenmustUse an empty line.
In any other location,shouldUse a blank line to reasonably separate the code content to ensure the readability and maintainability of the code.

Part 5 Variables, constants and functions

Chapter 1 · Definition

If not necessary,Try not toDefine global variables.
Define constants,mustuse#defineorconstAny one ofNoMixed use.
When defining a function, if the function body is not long,suggestionDeclare and define before the main function; if the function body is very long,shouldDeclare before the main function and define after the main function.

Chapter 2 · Naming

nameTry not toIf it is too long, otherwise it is easy to be exhausted when using an editor without automatic completion, and the expression is also easy to be too long, which affects the visual sense, readability and maintainability.
At the same time, nameNoUse overly simple and meaningless names,Try toThe function of this function is reflected in the naming. Except for the variable names given in the title.
It should be noted thatToo simple and meaninglessThe core of the word is meaningless. If a single letter has obvious meaning, it is not considered an irregular naming, such asforIn-housei, representing the vertexu、vwait.
Of course, when there are many variables, it is indeedNot recommendedNamed with a single letter.

postscript

That's about it. The code rules I gave here are actually relatively loose and have a lot of room for freedom.
If you need any additional content, please point it out!

Some newbies may ask, is Ma Feng really that important?
Of course there are. I have also mentioned many times above that the fundamental purpose of developing a good code style is to ensure the readability and maintainability of the code, and at the same time ensure the aesthetics of the code.
A good code style is undoubtedly extremely important for OIer. As the saying goes, "Coding is like the person". If you are an OIer with pursuit, then you should have a clean and unified code style.
Of course, if you decide to do programming in the future, you should also develop a good coding style, otherwise the project will be written as Shit Mountain sooner or later.

Okay, let’s just stop here, I wish you all love your OI career.

Update records

  • 2025/4/26 14:09This article has been officially completed and published.
<Previous Next>