Changes between Version 15 and Version 16 of StudentTips


Ignore:
Timestamp:
2012-03-20T11:08:11Z (12 years ago)
Author:
Martin Decky
Comment:

small improvements and additions

Legend:

Unmodified
Added
Removed
Modified

  • StudentTips

    v15 v16  
    11= Tips for (not only) students =
    22
    3 On this page, we provide tips for authors of HelenOS master and bachelor theses, and various software projects. The tips are based on previous experience in this area. For official guidance, please consult your thesis / project supervisor or mentor.
     3On this page, we provide tips for authors of HelenOS master and bachelor theses, various software projects and [GSOC Google Summer of Code participants]. However, many of the tips can be generally helpful to any contributors to HelenOS. The tips are based on previous experience in this area. For official guidance, please consult your thesis / project advisor, supervisor or mentor.
    44
    55----
    … …  
    1111== Writing tips ==
    1212
    13 This section is only relevant to you if one of the outcomes of your project is some kind of a written publication such as a thesis or design documentation.
     13This section is only relevant to you if one of the outcomes of your project is some kind of a written publication such as a paper, a thesis or design documentation.
    1414
    1515=== Content ===
    16   * If you provide some sort of HelenOS overview chapter, please do not blindly follow the pretty much outdated 0.2.0 design documentation (i.e. forget about pseudothreads) and stick to the things that seem relevant to your own thesis (e.g. no need to provide in-depth description of the kernel architecture if your focus is on some userspace application). There is also no point in retelling the early history of the project in each thesis.
    17   * If you provide a related work chapter, consider providing comparison with similar multiserver operating systems (if applicable), i.e. the Hurd and MINIX 3. These will be very interesting and useful as you will be comparing apples with apples and not apples with elephants.
     16  * If you provide some sort of HelenOS overview chapter, please do not blindly follow the pretty much outdated 0.2.0 design documentation (i.e. forget about ''pseudothreads'' and use the current terminology) and stick to the things that seem relevant to your own work (e.g. no need to provide in-depth description of the kernel architecture if your focus is on some userspace application). There is also no point in retelling the early history of the project in each thesis.
     17  * If you provide a related work chapter, consider providing comparison with similar microkernel multiserver operating systems (if applicable), i.e. the Hurd, L4 and MINIX 3. These will be very interesting and useful as you will be comparing apples with apples and not apples with elephants in case of comparing HelenOS with GNU/Linux or any other monolithic system.
    1818
    1919=== Form ===
    … …  
    2222=== Planning ===
    2323  * Getting the thesis into a good shape (grammatically, stylistically and visually) can take as much as half of the entire time you reserved for working on the text of the thesis. People don't usually believe this advice or don't take it seriously enough, but then all of them are found to have a very eventful and exciting submission week and the end result is not as good as it might have been if more time was spent on editing the thesis.
    24   * Most of the time, there will be people willing to proof-read your thesis, so plan ahead to allow enough time for these proof-readers to do you this favor and also to incorporate their suggestions.
    25 
    26 ----
     24  * Most of the time, there will be people willing to proof-read your thesis, so plan ahead to allow enough time for these proof-readers to do you this favour and also to incorporate their suggestions.
    2725
    2826== Coding tips ==
    … …  
    3028=== Implementation ===
    3129  * Stick to the [http://www.helenos.org/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.
    32   * 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.
     30  * 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.
    3331  * 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.
    3432  * 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.
    … …  
    4240  * Try to make more smaller commits than few larger commits.
    4341  * Unrelated changes should go into separate commits.
    44   * Don't forget to review your changes before committing them.
    45 
    46 ----
     42  * Don't forget to review your changes before committing them and avoid committing unintended changes (temporary hacks, purely debugging stuff) by accident.
    4743
    4844== Social interaction tips ==