ARTS Week 25


This week’s LeetCode problem is 371. Sum of Two Integers

Given two integers a and b, return the sum of the two integers without using the operators + and -.

The four cases according to the addition of two binary bits are as follows:

In the case of disregarding the carry, the result of the addition without **carry is ** a^b; and whether or not to carry depends on a&b, so the result of the carry is (a&b)<<1. Thus, we can split the sum of integers a and b into the sum of the carry-free addition of a and b and the carry-over result. Because each split can shift the least significant bit to the left by at least one bit, and because a and b can take negative numbers. Because signed integers are represented in two's complement, the above method also works for 0 and negative numbers.


This week’s Review is for the following article: Best practices for writing code comments

A lot of code comments does not mean its quality is guaranteed. Good comments should help others to understand the code more easily. Here are some suggestions from the author on how to ensure the quality of the code:

Rule 1: Comments should not duplicate the code.

A bad example

A more extreme example.

Rule 2: Good comments do not excuse unclear code.

Bad example, meaning of variable n is ambiguous

For a good example, the variable n should be renamed to bestNode, so that it can be understood by others without the need for comments.

Rule 3: If you can’t write a clear comment, there may be a problem with the code. The most infamous comment in the Unix source code is “You are not expected to understand this,” which appeared before some hairy context-switching code. Unfortunately, it turned out that he and co-author Ken Thompson didn’t understand it themselves and later had to rewrite it.

Rule 4: Comments should dispel confusion, not cause it. If your comment causes confusion instead of dispelling it, remove it.

Rule 5: Explain unidiomatic code in comments.

Bad example, code should not explain code that everyone can understand, unless you are writing a tutorial for newbies.

Rule 6: Provide links to the original source of copied code. Here is a good example:

Rule 7: Include links to external references where they will be most helpful. Sometimes, a link to the manual can also be given:

Rule 8: Add comments when fixing bugs. Here is a good example:

Rule 9: Use comments to mark incomplete implementations. Here is a example:

In fact, many code comments are actually the same as shown in the following image:

For your consideration…


Similarities and differences between the clock() function and the gettimeofday() function:

  • Common point: both can obtain the current time, and then obtain the running time of a certain code by calculating the difference between the current time before and after
  • Difference: clock() is a C language library function, which means it can be used under any system; while the gettimeofday() function is only a function in Linux system, so it can only be used in Linux system use.


The trilogy of tutorials on reading and writing CSV in C language has been released. The reading data of each platform is obviously more than that of the ARTS series. It can be seen that the platform and everyone prefer tutorials with a specific point, and more articles of this type will be created in the future.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store



A programmer. Share knowledge of programming, operating system, Linux kernel, and reading, thinking etc. Let us maintain a beginner mend and grow together!