repl.it
linktP:
Admin tP → Deliverables → After the PED
Admin tP → Grading → Expectation on testing
🤔 How much testings is enough? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.
There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The weaker your tests are, the higher the risk of bugs, which will cost marks if not fixed before the final submission.
Admin tP → Grading → Code Quality Tips
At least some evidence of these (see here for more info)
No coding standard violations e.g. all boolean variables/methods sounds like booleans.
SLAP is applied at a reasonable level. Long methods or deeply-nested code are symptoms of low-SLAP.
No noticeable code duplications i.e. if there multiple blocks of code that vary only in minor ways, try to extract out similarities into one place, especially in test code.
Evidence of applying code quality guidelines covered in the module.
Admin tP → Deliverables → Project Portfolio Page
At the end of the project each student is required to submit a Project Portfolio Page.
Team-tasks are the tasks that someone in the team has to do. Marks allocated to team-tasks will be divided among team members based on how much each member contributed to those tasks.
Examples of team-tasks
Here is a non-exhaustive list of team-tasks:
Keep in mind that evaluators will use the PPP to estimate your project effort. We recommend that you mention things that will earn you a fair score e.g., explain how deep the enhancement is, why it is complete, how hard it was to implement etc..
[Optional] Contributions to the User Guide (Extracts): Reproduce the parts in the User Guide that you wrote. This can include features you implemented as well as features you propose to implement.
The purpose of allowing you to include proposed features is to provide you more flexibility to show your documentation skills. e.g. you can bring in a proposed feature just to give you an opportunity to use a UML diagram type not used by the actual features.
[Optional] Contributions to the Developer Guide (Extracts): Reproduce the parts in the Developer Guide that you wrote. Ensure there is enough content to evaluate your technical documentation skills and UML modelling skills. You can include descriptions of your design/implementations, possible alternatives, pros and cons of alternatives, etc.
[Optional] If you plan to use the PPP in your Resume, you can also include your SE work outside of the module (will not be graded).
docs/team/githbub_username_in_lower_case.md
e.g., docs/team/goodcoder123.md
background graphics
option as well if you wish.Admin Using This Webiste → Saving as PDF Files
Content | Recommended | Hard Limit |
---|---|---|
Overview + Summary of contributions | 0.5-1 | 2 |
[Optional] Contributions to the User Guide | 1-3 | |
[Optional] Contributions to the Developer Guide | 3-6 |
Admin tP → mid-v2.1 → Making the Code RepoSense-Compatible
Ensure your code is i.e., RepoSense can detect your code as yoursRepoSense-compatible and the code it attributes to you is indeed the code written by you, as explained below:
</>
icon against your name and verify that the lines attributed to you (i.e., lines marked as green) reflects your code contribution correctly. This is important because some aspects of your project grade (e.g., code quality) will be graded based on those lines.Admin Tools → RepoSense
We will be using a tool called RepoSense to make it easier for you to see (and learn from) code written by others, and to help us see who wrote which part of the code.
Viewing the current status of code authorship data:
2. If the code does not match the actual authorship:
Here are the possible reasons for the code shown not to match the code you wrote:
In those cases, you can provide more information to RepoSense to rectify the situation, in the following way:
For simple cases such as the following, you can create a PR to update our config files here. The meaning of the config files are given in the RepoSense user guide.
user.name
sFor more complicated needs, follow the instructions below this box. If you are not sure which option to use, please post in the forum to ask.
config.json
file to your repo (as specified by one of the two methods),
"displayName": "CS2113-T11-4 ABDUL ... JAVID",
"authorNames": ["theMyth", "theLegend", "The Gary"]
config.json
in the .gitignore
file of your repo as /config.json
so that it ignores the config.json
produced by the app but not the _reposense/config.json
.@@author
annotations, please follow the guidelines below:Adding @@author
tags to indicate authorship
@@author
tags indicate authorshipMark your code with a //@@author {yourGithubUsername}
. Note the double @
.
The //@@author
tag should indicates the beginning of the code you wrote. The code up to the next //@@author
tag or the end of the file (whichever comes first) will be considered as was written by that author.
Here is a sample code file:
//@@author johndoe
method 1 ...
method 2 ...
//@@author sarahkhoo
method 3 ...
//@@author johndoe
method 4 ...
If you don't know who wrote the code segment below yours, you may put an empty //@@author
(i.e. no GitHub username) to indicate the end of the code segment you wrote. The author of code below yours can add the GitHub username to the empty tag later.
Here is a sample code with an empty author
tag:
method 0 ...
//@@author johndoe
method 1 ...
method 2 ...
//@@author
method 3 ...
method 4 ...
The author tag syntax varies based on file type e.g. for java, css, fxml. Use the corresponding comment syntax for non-Java files.
Here is an example code from an xml/fxml file.
<!-- @@author sereneWong -->
<textbox>
<label>...</label>
<input>...</input>
</textbox>
...
Do not put the //@@author
inside java header comments.
👎
/**
* Returns true if ...
* @@author johndoe
*/
👍
//@@author johndoe
/**
* Returns true if ...
*/
Annotate both functional and test code There is no need to annotate documentation files.
Annotate only significant size code blocks that can be reviewed on its own e.g., a class, a sequence of methods, a method.
Claiming credit for code blocks smaller than a method is discouraged but allowed. If you do, do it sparingly and only claim meaningful blocks of code such as a block of statements, a loop, or an if-else statement.
Do not try to boost the quantity of your contribution using unethical means such as duplicating the same code in multiple places. In particular, do not copy-paste test cases to create redundant tests. Even repetitive code blocks within test methods should be extracted out as utility methods to reduce code duplication. Individual members are responsible for making sure code attributed to them are correct. If you notice a team member claiming credit for code that he/she did not write or use other questionable tactics, you can email us (after the final submission) to let us know.
If you wrote a significant amount of code that was not used in the final product,
{project root}/unused
//@@author {yourGithubUsername}-unused
to mark unused code in those files (note the suffix unused
)
e.g.//@@author johndoe-unused
method 1 ...
method 2 ...
Please put a comment in the code to explain why it was not used.
If you reused code from elsewhere, mark such code as //@@author {yourGithubUsername}-reused
(note the suffix reused
)
e.g.
//@@author johndoe-reused
method 1 ...
method 2 ...
You can use empty @@author
tags to mark code as not yours when RepoSense attribute the to you incorrectly.
Code generated by the IDE/framework, should not be annotated as your own.
Code you modified in minor ways e.g. adding a parameter. These should not be claimed as yours but you can mention these additional contributions in the Project Portfolio page if you want to claim credit for them.
config.json
file you added and/or the annotated code to your repo. We'll use that information the next time we run RepoSense (we run it at least once a week).We recommend you ensure your code is RepoSense-compatible by v2.0