This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
haas:fall2020:discrete:projects:bdt1 [2018/09/17 13:38] – external edit 127.0.0.1 | haas:fall2020:discrete:projects:bdt1 [2020/09/30 12:11] (current) – [Submission] wedge | ||
---|---|---|---|
Line 60: | Line 60: | ||
As such, the following implementation restrictions are also in place: | As such, the following implementation restrictions are also in place: | ||
- | * use any **break** or **continue** statements sparingly. I am not forbidding their use, but I also don't want this to turn into a lazy solution free-for-all. I am letting you use them, but with **justification**. | + | * use any **break** or **continue**, or other flow redirection |
* **justification** implies some thoughtful why/how style comments explaining how a particular use of one of these statements is effective and efficient (not: "I couldn' | * **justification** implies some thoughtful why/how style comments explaining how a particular use of one of these statements is effective and efficient (not: "I couldn' | ||
* absolutely **NO** infinite loops (**while(1)** or the like). | * absolutely **NO** infinite loops (**while(1)** or the like). | ||
- | * no forced redirection of the flow of the process (no seeking to the end of the file to grab a max size only to zip back somewhere else: deal with the data in as you are naturally encountering it). | + | * no forced redirection of the flow of the process (no seeking to the end of the file to grab a max size only to zip back somewhere else: deal with the data in as you are naturally encountering it; no telling; no " |
* All " | * All " | ||
* **NO** logic shunts (ie having an if statement nested inside a loop to bypass an undesirable iteration)- this should be handled by the loop condition! | * **NO** logic shunts (ie having an if statement nested inside a loop to bypass an undesirable iteration)- this should be handled by the loop condition! | ||
+ | * at most, only **one** return() statement per function. Error terminations should use **exit()** | ||
- | Basically, I am going loosen my implementation restriction grip for this project: I would like you NOT to disappoint me. Write clean, effective code... show me that you have learned something from this class. | + | Basically, I am going loosen my implementation restriction grip for this project: I would like you NOT to disappoint me. Write clean, well-indented, |
=====Program Specifications===== | =====Program Specifications===== | ||
Line 129: | Line 130: | ||
You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches. | You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches. | ||
+ | |||
+ | What I will be looking for: | ||
+ | |||
+ | < | ||
+ | 156: | ||
+ | *: | ||
+ | *: | ||
+ | *: | ||
+ | *: | ||
+ | *:bdt1:bdt1 runtime output conforms to specifications [26/26] | ||
+ | *:bdt1:bdt1 eval check tests succeed [26/26] | ||
+ | *:bdt1:bdt1 committed, pushed to lab46 repository [13/13] | ||
+ | </ | ||
+ | |||
+ | Additionally: | ||
+ | * Solutions not abiding by spirit of project will be subject to a 25% overall deduction | ||
+ | * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction | ||
+ | * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction | ||
+ | * Solutions not organized and easy to read are subject to a 25% overall deduction |