Changes between Version 26 and Version 27 of StudentTips

Timestamp:

2016-02-19T13:31:39Z (8 years ago)

Author:

Martin Decky

Comment:

typos

StudentTips

@@ -9 +9 @@
   * 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. Remember that HelenOS is a portable multiplatform operating system. Your generic code is supposed to run everywhere where HelenOS can run. This ranges from small little-endian ARM devices to much bigger multiprocessor 64-bit big-endian UltraSPARC servers.
   * 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.
-  * Self-contained code is good, but avoid poorly integrated code. Poorly integrated code is pointlessly concentrated in one subdirectory of the source tree. For example, putting new generic ADT's and IPC primitives under the networking directory is a sign of poorly integrated code.
-  * As with the text of your thesis, similar citation rules should apply in your code. When using third party code, always give credit where the credit is due, always follow the license of the third party code. It would be kind of embarrassing to discover portions of e.g. Linux header file in code which you advertise as yours.
+  * Adhere to good coding practices, such as adequate commenting, avoiding dense code, using horizontal spacing as visual delimiters 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.
+  * Self-contained code is good, but avoid poorly integrated code. Poorly integrated code is pointlessly concentrated in one subdirectory of the source tree. For example, putting new generic ADTs and IPC primitives under the networking directory is a sign of poorly integrated code.
+  * As with the text of your thesis, similar citation rules should apply for your code. When using third-party code, always give credit where the credit is due, always follow the license of the third-party code. It would be kind of embarrassing to discover portions of e.g. Linux header file in code which you advertise as yours.
   * 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.