Code_Crafters——Code Standards, Sprint Tasks, and Plans

Description

This assignment belongs to which course	https://bbs.csdn.net/forums/ssynkqtd-04
Where this assignment is required	https://bbs.csdn.net/topics/617606376
Team name	Code Crafters
The goal of this assignment	Alpha Sprint-Code Standards, Sprint Tasks, and Plans
The team project	Student Buddy
Other reference	Huawei Internal Code Standards

Code Standards

General Principle

• Clear, easy to maintain, easy to refactor.
• It’s simple, easy to understand, and easy to implement.
• The style is unified, and the overall style of the code remains unified.
• Universal, following the industry’s common programming specifications.

Layout and Formatting

• Blocks are written in an indented style, indented with Spaces instead of tabs (‘\t’), and indented by 4 Spaces per level.
• The K&R style is used as the brace wrap style, that is, the function opening brace starts with another line and monopolizes the line, the other opening brace follows the end of the statement, and the closing brace monopolizes the line, unless followed by the rest of the same statement, such as the else/else if or semicolon of the if statement.
• Conditional and loop statements use braces, and case/default statements are indented one level relative to switch.
• Write only one statement in a line and do not exceed 120 characters. If the statement cannot be shortened, write it in a line.
• When a function is defined, the return type of the function, along with other modifiers, is declared along with the function name.

Name

• Use the hump style for naming, which uses a mix of upper- and lower-case letters and separates different words by the first letter of the word
• The naming of global functions, global variables, macros, type names, and enumerations should be accurately described and globally unique.
• Local variables, or variables that are members of structures or consortiums, should be named as briefly as possible, provided that their meaning can be accurately expressed.

Comment

• The content of the comment should be clear and concise, and the meaning should be accurate to prevent the ambiguity of the comment.
• Comments are made at the functional, intent level of the code, that is, comments explain the intent that the code is difficult to express directly, rather than just repeating the description of the code.
• Comments at the function declaration describe function functionality, performance, and usage, including input and output parameters, function return values, reentrant requirements, etc. The definition describes the function function and implementation points in detail, such as the brief steps of implementation, the reason for implementation, and the design constraints.
• Global variables should be annotated in detail, including the description of their functions, value ranges, and precautions for accessing them.
• Avoid using abbreviations in comments unless they are industry-common or standardized within a subsystem.
• The header of the file should be commented, and it is recommended that the annotation list: copyright description, version number, generation date, author name, function description, relationship with other files, modification log, etc.
• Note style should be unified. It is recommended to preferentially select /* */. There should be 1 space between the comment character and the comment content.
• Comments should be placed above or to the right of their code. The comments above, with no empty lines between them, remain indented as in the code. The comment on the right is separated by at least 1 space from the code. If you have more than one right comment, it’s nice to align it up and down.

Variable

• A variable has only one function, do not use a variable for multiple purposes.
  Prevent local variables from having the same name as global variables.
  Do not use global variables or use them sparingly.
• When defining local variables of a function, control the space occupied by variables to avoid program failure due to excessive stack space. For example, if you need a large array, you can dynamically allocate memory to avoid occupying too much stack space.
  Initialize variables before first use.
• A variable that points to a resource handle or descriptor and is assigned a new value immediately after the resource is released, including Pointers, socket descriptors, file descriptors, and other variables that point to the resource.
• Returning the address of a local variable outside its scope is prohibited.
• If you want to use variables from other modules, you should try to avoid direct access to variables, but through a unified function wrapper or macro wrapper.

Function

• Duplicate code should be distilled as much as possible into functions.
• Do not add more than 40-50 lines of new functions.
• Inline functions should be as short as possible, avoiding more than 10 lines (non-empty, non-comment).
• Avoid deep nesting of code blocks for functions.
• Functions should avoid the use of global variables, static local variables, and I/O operations, and should be used centrally where unavoidable.

Sprint Tasks

• Complete the overall framework construction
• The front end completes each basic plate
• The back-end implements interfaces required by each function
• Realize the basic functions of each plate
• Test the basic functions of each plate

Sprint Plans

Time	Task
Day1 & Day2	Realize registration, login, send mail function
Day3 & Day4	Realize friends, confession, chat function
Day5 & Day6	Design user interface
Day7 & Day8	Set up the front - and back-end interfaces
Day9 & Day10	Test the functions