feat(software): changed software charter to make a bit more sense
This commit is contained in:
parent
ad8ca36232
commit
5bac5ada19
178
Commenting Pratices.md
Normal file
178
Commenting Pratices.md
Normal file
@ -0,0 +1,178 @@
|
||||
|
||||
# When does code need comments
|
||||
|
||||
## Needs Comments
|
||||
This example needs comments
|
||||
```rust
|
||||
fn main () {
|
||||
let length1 = 8;
|
||||
let width1 = 4;
|
||||
|
||||
println!("The area of a rectangle is {} square units.",
|
||||
area(length1, width1)
|
||||
}
|
||||
|
||||
fn area (length: i32, width: i32) -> i32 {
|
||||
length * width
|
||||
}
|
||||
```
|
||||
|
||||
Not really great nothing related needs specifically named variables that losely relate to one another.
|
||||
|
||||
Variables are ambiguous to their relationship, for example is `length1` related to `rectange1` or some other rectangle (who knows)
|
||||
|
||||
|
||||
## Needs comments for a differnent reason, not well defined relationship
|
||||
Here is a bit better but still needs comments to define the relationship and what is going on
|
||||
```rust
|
||||
fn main () {
|
||||
let rectangle1 = (8, 4);
|
||||
println!("The area of a rectangle is {} square units.",
|
||||
area(rectangle1)
|
||||
);
|
||||
}
|
||||
|
||||
fn area (dimensions: (i32, i32)) -> i32 {
|
||||
dimensions.0 * dimensions.1
|
||||
}
|
||||
```
|
||||
Now what does the first and second index of the tuple mean?
|
||||
|
||||
It could be width then length this is still ambugious
|
||||
|
||||
## Very Little Comments Required
|
||||
This is very clear from a first read but it could use some comments
|
||||
```rust
|
||||
struct Rectangle {
|
||||
length: u32,
|
||||
width: u32,
|
||||
}
|
||||
fn main () {
|
||||
let rect1 = Rectangle {
|
||||
length: 8,
|
||||
width: 4,
|
||||
};
|
||||
println!("The area of a rectangle is {} square units.",
|
||||
area(&rect1)
|
||||
);
|
||||
}
|
||||
|
||||
fn area (rect: &Rectangle) -> u32 {
|
||||
rect.length * rect.width
|
||||
}
|
||||
```
|
||||
|
||||
Could be better due to the way that shapes all have unique area formulas
|
||||
|
||||
In this case it should be a method that implements a `trait` (a common shared method, also known as a interface) so that its relationship is very well defined
|
||||
|
||||
## The Worst Code I Have Written
|
||||
|
||||
This is when things needs to be refactored because comments cannot save it
|
||||
|
||||
This code was written by Brock
|
||||
```javascript
|
||||
<div id="Sponsor">
|
||||
<h2 className="SponsorsTitle">Current Sponsors</h2>
|
||||
{/* shows the current sponsors only after the data has been recieved */}
|
||||
{currentSponsorsDict === undefined ? (
|
||||
<p>Loading...</p>
|
||||
) : (
|
||||
<>
|
||||
{/* gets the outmost name of the Object Name of tier*/}
|
||||
{Object.keys(currentSponsorsDict).map((sponsorsTier) => {
|
||||
return (
|
||||
<div className="Sponsors">
|
||||
<h3>{sponsorsTier}</h3>
|
||||
{/* gets key form list of tier */}
|
||||
{Object.keys(currentSponsorsDict[sponsorsTier]).map(
|
||||
(sponsorsKey) => {
|
||||
return (
|
||||
<>
|
||||
{/* gets name out of object and gets data of that sponsor preped */}
|
||||
{Object.keys(
|
||||
currentSponsorsDict[sponsorsTier][sponsorsKey]
|
||||
).map((sponsorName) => {
|
||||
let sponsorData =
|
||||
currentSponsorsDict[sponsorsTier][sponsorsKey][
|
||||
sponsorName
|
||||
];
|
||||
return (
|
||||
<a
|
||||
href={sponsorData.Url}
|
||||
target="_blank"
|
||||
rel="noreferrer">
|
||||
<div>
|
||||
<h4>{sponsorName}</h4>
|
||||
<img
|
||||
src={sponsorData.LogoUrl}
|
||||
alt={sponsorName + "'s Logo"}
|
||||
/>
|
||||
</div>
|
||||
{(sponsorsTier !== "Silver Tier" ||
|
||||
sponsorsTier !== "Bronze Tier") && (
|
||||
<div>
|
||||
<p>{sponsorData.DescriptionAboutSponsor}</p>
|
||||
</div>
|
||||
)}
|
||||
</a>
|
||||
);
|
||||
})}
|
||||
</>
|
||||
);
|
||||
}
|
||||
)}
|
||||
</div>
|
||||
);
|
||||
})}
|
||||
</>
|
||||
)}
|
||||
</div>
|
||||
<div id="Sponsor">
|
||||
<h2
|
||||
className="SponsorsTitle"
|
||||
id="SponsorEnd">
|
||||
Past Sponsors
|
||||
</h2>
|
||||
{/* shows past sponsors only when recieved, do not duplicate the sponsors from current ones */}
|
||||
{pastSponsorsDict === undefined ? (
|
||||
<p>Loading...</p>
|
||||
) : (
|
||||
<>
|
||||
{/* gets keys o objects in list */}
|
||||
{Object.keys(pastSponsorsDict).map((pastSponsorKey) => {
|
||||
return (
|
||||
<div className="Sponsors">
|
||||
{/* gets name of sponsor then uses it to get data of past sponsor */}
|
||||
{Object.keys(pastSponsorsDict[pastSponsorKey]).map(
|
||||
(pastSponsorName) => {
|
||||
let pastSponsors =
|
||||
pastSponsorsDict[pastSponsorKey][pastSponsorName];
|
||||
return (
|
||||
<a
|
||||
href={pastSponsors.Url}
|
||||
target="_blank"
|
||||
rel="noreferrer">
|
||||
<div>
|
||||
<h4>{pastSponsorName}</h4>
|
||||
<img
|
||||
src={pastSponsors.LogoUrl}
|
||||
alt={pastSponsorName + "'s Logo"}
|
||||
/>
|
||||
</div>
|
||||
</a>
|
||||
);
|
||||
}
|
||||
)}
|
||||
</div>
|
||||
);
|
||||
})}
|
||||
</>
|
||||
)}
|
||||
</div>
|
||||
</div>
|
||||
);
|
||||
};
|
||||
|
||||
export default OurSponsors;
|
||||
```
|
@ -1,5 +1,6 @@
|
||||
# Software Charter
|
||||
|
||||
Authors and when it was updated
|
||||
- Brock (2025)
|
||||
## How does Software Fit in?
|
||||
|
||||
### What is Software at Baja
|
||||
@ -15,8 +16,14 @@ Repeated again for Highlighting
|
||||
```
|
||||
You get out what you put in.
|
||||
```
|
||||
If you don't show up and do work you don't learn anything from more Senior Members.
|
||||
If you don't show up and do work you don't learn anything from more Senior Members or from past mistakes you *CAN* and should make.
|
||||
|
||||
To further emphasize this the core belief that the software lead should have is that:
|
||||
- *We **GET** to work at building something cool and then go home after the day is over*.
|
||||
|
||||
This is to further emphasize that it is a privalige to do work at Baja but also baja is not a job its a place to learn additional skills that the school cannot teach intensively, such as code smells, reviewing code, and project mangement.
|
||||
|
||||
*This is **NOT** a core belief* and more so an interesting world veiw on everything you will do and have done
|
||||
```
|
||||
Communication both written and oral is based on signals or promises with the receiving party obtaining those signals and promises.
|
||||
```
|
||||
@ -32,29 +39,30 @@ It is important to note that UCalgary Baja does not exclusively recruit “car e
|
||||
I would look for anyone who is passoinate or wants to learn in their appilcation, this shows that they want to do software, you will be able to tell if it is a mech application, use your judgement to determine if you want the mech applicant
|
||||
|
||||
## Coding Coduct
|
||||
This section outlines how programming and coding in all languages should generally be followed.
|
||||
|
||||
This section outlines how programming and coding in all languages should generally be followed:
|
||||
|
||||
1. Readable code is valued above all else ie. Variable names that make sense, clear function names
|
||||
1. Comment code even if it is obnoxious make it so that you or anyone besides yourself in 10 years can read what is going on. Programs like ChatGPT are allowed to comment code automatically just as long as they make sense to you six months down the road
|
||||
1. Use the Prettier extension as the default code formatter so that the code is consistent
|
||||
1. Use git and use a new branch to create a new feature (be careful of the base of the branch)
|
||||
1. Use pull requests to the dev branch to merge code
|
||||
|
||||
2. Comment code even if it is obnoxious make it so that you or anyone besides yourself in 10 years can read what is going on. Programs like ChatGPT are allowed to comment code automatically just as long as they make sense to you six months down the road
|
||||
[Here] is some guideline of when and when to not comment
|
||||
3. Use the Prettier extension as the default code formatter or use the `rustfmt` commnad so that the code is consistent
|
||||
4. Use git and use a new branch to create a new feature (be careful of the base of the branch)
|
||||
5. Use pull requests to the dev branch to merge code
|
||||
```
|
||||
DO NOT MERGE TO THE PRODUCTION BRANCH (main or master normally)
|
||||
DO NOT PUSH CODE DIRECTLY TO THE PRODUCTION BRANCH (main or master normally)
|
||||
```
|
||||
|
||||
1. Examples of base templates in most common languages are available below
|
||||
1. Try to make code as modular and reusable as possible
|
||||
1. Use ChatGPT but be warned you will spend more time on debugging than coding and ***most importantly YOU WONT LEARN***, USE IT FOR REGEX
|
||||
1. Please include a permanent email and name if you write any code, this is just for questions on what x does (not mandatory)
|
||||
- If you write unreadable code you get emails in the future about it
|
||||
- Remove emails if completely refactored (75% of the code has been changed in some way)
|
||||
6. Examples of base templates in most common languages are available [here](./SoftwareFnStandards.md)
|
||||
7. Try to make code as modular and reusable as possible
|
||||
8. It is up to the lead of the project as well as other factors (like relative skill level) but test driven development is preferred
|
||||
9. Google Docs or Stack overflow before using ChatGPT
|
||||
10. Use ChatGPT but be warned you will spend more time on debugging than coding and ***most importantly YOU WONT LEARN***, USE IT FOR REGEX
|
||||
11. Please do not become a "human clipboard". At that point you do not get anything out of coming to baja
|
||||
12. Please include a permanent email and name if you write any code, this is just for questions on what x does (not mandatory)
|
||||
- If you write unreadable code you get emails in the future about it
|
||||
- Remove emails if completely refactored (75% of the code has been changed in some way)
|
||||
```
|
||||
DO NOT USE THIS TO GET ALUMNI TO DO YOUR WORK
|
||||
```
|
||||
1. Please do not become a "human clipboard". At that point you do not get anything out of coming to baja
|
||||
|
||||
|
||||
## How To's
|
||||
|
||||
@ -105,9 +113,9 @@ This document outlines the reporting structure within the Software Subteam. Each
|
||||
|
||||
##### Junior Member
|
||||
- **Reports to:** Software Lead and Senior Member
|
||||
- **Min Requirements:** New to the club this year
|
||||
- **Min Requirements:** New to the club this year (0-0.9 years)
|
||||
- **Roles:** Mentee (Need, dependent on year), design input
|
||||
- **Language Access:** Python, HTML, CSS, JavaScript, JSON, XML, JSON, Lua, Golang, Bash (basic commands and git)
|
||||
- **Language Access:** Python, HTML, CSS, JavaScript, JSON, XML, JSON, Lua, Golang (as pair programming), Rust (as pair programming) Bash (basic commands and git)
|
||||
- **Summary:** They are new and here to learn, they can give limited amounts of feedback about designs (due to a lack of knowledge)
|
||||
|
||||
### Additional Context
|
||||
@ -144,14 +152,13 @@ based upon the 2018 Baja Charter, taylored to software
|
||||
- Your position on this team is a privilege, not a right.
|
||||
- All members will follow through with commitments in a timely matter or inform your Team Lead/Team Captain if you cannot.
|
||||
- Will be present and attend meetings/workdays on time at the times specified.
|
||||
- Unless Exceptions are given either by the Software Lead or Team Captain
|
||||
- This includes an Internship program where Wednesdays are optional
|
||||
- Exams always
|
||||
- Safety always
|
||||
- Software Lead is on Internship, Wednesdays will either be optional or lead by a Senior member or Future Software Lead
|
||||
- Unless Exceptions are given either by the Software Lead or Team Captain
|
||||
- This includes an Internship program where Wednesdays are optional
|
||||
- Exams always
|
||||
- Safety always
|
||||
- Software Lead is on Internship, Wednesdays will either be optional or lead by a Senior member or Future Software Lead
|
||||
- Team members will need to be a part of all phases of your assigned project and possibly projects that you aren't part of - Design, & Coding. This ensures that mistakes, issues, and concerns are addressed ASAP and corrected accordingly.
|
||||
- Asking questions is encouraged and is the greatest way for you to learn. Every member will be open to taking questions. If you are unable to answer a question either admit that “I don’t know”, or suggest someone who may be better qualified to answer the question. Asking questions is beneficial for both parties as it expands the asker’s knowledge base, and keeps the question recipient current with their knowledge
|
||||
- Googling the docs or Stackoverflow is a great start
|
||||
|
||||
#### Juniors
|
||||
- Are expected to work and ask questions. Enthusiasm to learn and a positive attitude is a must!
|
||||
|
Loading…
x
Reference in New Issue
Block a user