Changes between Version 18 and Version 19 of StudentTips

Timestamp:

2012-09-12T14:48:29Z (12 years ago)

Author:

Jakub Jermář

Comment:

New tips.

StudentTips

@@ -27 +27 @@
 
 === Implementation ===
+  * Do not impose artificial limits on your implementation. If your project is fundamentally platform-neutral, for example when what you implement is a sophisticated data structure or a new file system, do not restrict the implementation to a single supported processor architecture, byte order or word width.
   * Stick to the [wiki:CStyle HelenOS coding style]. We really mean this. Your failure to adhere to the coding style of the surrounding code requires someone else's extra work to perform the cleanup after you. The fact that you may prefer another coding style is quite insignificant in the context of HelenOS. Get over it and use our coding style.
   * Adhere to good coding practices, such as adequate commenting, avoiding dense code, using horizontal spacing as visual delimiter and keeping the block nesting level under control. Also pay attention to seemingly subtle and unimportant decisions, such as proper naming of identifiers, following a coherent naming pattern, etc. Remember that the code is written once, but read many times. Do not make it harder for the reader than it is strictly necessary.
@@ -33 +34 @@
   * Be open-minded. If you are designing a new subsystem or some sort of interface for HelenOS, it may be convenient to do it exactly how it is done in e.g. Linux. Please don't do that, especially not if the only reason would be because Linux does it that way. Remember that cloning a legacy system is not our goal. When evaluating approaches to a problem in other operating systems, use critical thinking and try to find problems of and ways to improve their solutions.
   * Always use English for writing comments.
+
+=== Testing ===
+  * Make sure your changes do not break the build of any of the supported configurations by running `make check`.
+  * Always test on as many architectures and configurations as possible. When applicable, test your changes on both 32-bit and 64-bit, little-endian and big-endian machines, single processor as well as multi-processor builds and configurations.
+  * When possible, test on real hardware too.
 
 === Source history ===