14 KiB
Baja Software Comment and Function Template
Why and How To Comment
How long do you think this code will be used? 1 year? 1 decade? 4 weeks?
In Baja Software it should be belived that at some point you will be gone before the end of the lifetime of the software application.
Since you dont know when the end of the software's lifetime is; make life easier on both your future self and new juniors by comments the code, you dont have to comment line by line, but anything that isnt overtly clear should be commented.
A general guidline to comments:
- Comment Functions/Methods using the Standard Function Template
- Anything unclear to your past self (before creating it) should be commented
- At minimum comment explain what a "block" or scope does
- The rule in highest order can "overshadow" lower rules making them not required, for example a function that adds two integers does not need anything more than a well written standard function template
You don't know so make life easier on yourself and new juniors comment on what your code does, it doesn't have to be line by line but at least explain a "block" or a related section of code to the purpose/what it does.
Templates
All templates based off JSDoc standard can be found here and markdown
Quick Links
- JavaScipt
- Svelte/Sveltekit
- Python
- Rust
- C++
- C
- Java/C#
- Go/Golang
- Lua
- Terraform
- HTML
- JSON, YAML, XML, CSS
- Bash
- Github Actions
JavaScript
Uses JSDoc standard
//More preferred arrow function just needs to call function and does function immediately
/**
* @param {Object} inputVar - one argument into the function should be its name
* @param {number} b - one argument into the function should be its name
* @returns {Promise<number>} c - what the program returns with type
* @description A brief description of what the function does
* @author Name <semiperminant@exmaplemail.com>
// semi-permanent email, do not need to respond but try to be a good alumni
*/
const exampleFunct = (inputVar) => {
// comments annotate the line below them
// constant variable cannot change, not strongly typed
const varExample0 = 0;
// local variable, not strongly typed can be any data type
let varExample1 = 0;
// global variable, not strongly typed can be any data type
var varExample2 = 0;
// example function does nothing significant
return 0;
};
/**
* @param {Object} inputVar - one argument into the function should be its name
* @param {number} b - one argument into the function should be its name
* @returns {Promise<number>} c - what the program returns with type
* @description A brief description of what the function does
* @author Name <semiperminant@exmaplemail.com>
// semi-permanent email, do not need to respond but try to be a good alumni
*/
function exampleFunct2(inputVar) {
// comments annotate the line below them
// constant variable cannot change, not strongly typed
const varExample0 = 0;
// local variable, not strongly typed can be any data type
let varExample1 = 0;
// global variable, not strongly typed can be any data type
var varExample2 = 0;
// example function does nothing significant
return 0;
}
Svelte/SvelteKit
<script>
// comments annotate the line below them
// constant variable cannot change, not strongly typed
const VAREXAMPLE0 = 0;
// local variable, not strongly typed can be any data type
// this is a reactive variable that has a default value of 0
let varExample1 = $state(0);
// global variable, not strongly typed can be any data type
var varExample2 = 0;
let { children, otherProp } = $props();
//Use either sytle, function is preferred, use preferred svelte shorthand when appropriate
/**
* @param {Object} inputVar - one argument into the function should be its name
* @param {number} b - one argument into the function should be its name
* @returns {Promise<number>} c - what the program returns with type
* @description A brief description of what the function does
* @author Name <semiperminant@exmaplemail.com>
// semi-permanent email, do not need to respond but try to be a good alumni
*/
const exampleFunct = (inputVar) => {
// example function does nothing significant
return 0;
};
/**
* @param {Object} inputVar - one argument into the function should be its name
* @param {number} b - one argument into the function should be its name
* @returns {Promise<number>} c - what the program returns with type
* @description A brief description of what the function does
* @author Name <semiperminant@exmaplemail.com>
// semi-permanent email, do not need to respond but try to be a good alumni
*/
function exampleFunct2(inputVar) {
// example function does nothing significant
return 0;
}
</script>
<!-- Main -->
<div>
<h1>Does nothing</h1>
{@render children}
</div>
<!-- Main End -->
{#snippet repeatedCode(inputProp)}
<p>{inputprop}</p>
{/snippet}
<style>
/* styles are strongly related unless stated global */
div {
background-color: red;
}
/* every h1 will have a blue background with the user of :global() */
:global(h1) {
background-color: blue;
}
</style>
Python
# comments normally annotate the line below, python functions/classes/methods are the only expection
def example_funct(input_var:type):
"""
What function does
`PARAMS`:
- Name_of_var `type` - Addtional details of what is required
`RETURNS`:
- Name_of_var `type` - Additional details of what is required
`AUTHOR(S)`:
- Your Name <<semiperminant@exmaplemail.com>
- Another Example <different@examplemail.com>
semi-permanent email, do not need to respond but try to be a good alumni
"""
# example variable can be anything not just an int
var_example = 0
# example function does nothing significant
return 0
Rust
Not happy with this
Rust is a very unique language and a great guiding book. You can learn more here about Rust's Documentation for publishing packages.
The goal of this is to passively train you how to produce comments and code worthy of being open source and industry level.
Due to the language's interesting module seperating when creating a large program. All members will be involved in the creation of all functions and how they should be seperated into their groups of related ideas.
First off the file tree structure will look like this example
src/
├── lib.rs
└── front_of_house/
├── mod.rs
├── a_different_mod.rs
└── other_module_linked_in_modrs.rs
These are all related functions in front of house, for small modules do not make a sub directory only large or major functions should be seperated
mod.rs defines all of the other modules/functions/structs (must be defined as pub) in the font_of_house folder/module
Where mod.rs is like this
//! Describes what front_of_house module provides
//! All functionality in other files this serves as a connector
//! Main idea and a run should be in this file
//! re exports go here as well
pub mod a_different_mod;
// only split if a different losely related idea is needed (the sub idea more relates to itself than to the parent)
pub mod other_module_linked_in_modrs;
Also where other_module_linked_in_modrs.rs looks like this
/// What the function does
///
/// ### Params
///
/// - input_var - Description of what the input should be.
/// - b - Description of the second input parameter.
///
/// ### Returns
///
/// - Description of the return value.
///
/// # Example Usage
///
/// ```rust
/// // how a user would use this function, replace ex_crate with actual path to use function
/// // this is how a public but internal module would be used by an outside user (ex_crate needs to be changed)
/// let result = crate::front_of_house::other_module_linked_in_modrs::example_funct(5, 10);
/// assert_eq!(result, 15);
/// ```
/// # Author (s)
///
/// - Name <semiperminant@exmaplemail.com>
/// - Another Example <different@examplemail.com>
/// semi-permanent email, do not need to respond but try to be a good alumni
pub fn example_funct(input_var: i32, b: i32) -> i32 {
// example variable can be anything not just an integer
let var_example = 0;
// example function does nothing significant
var_example + input_var + b
}
One all of the main modules have been decided upon a senior member or lead will be assigned to that module will then be responsible and will break the module into sub components to assign out to implement.
The team will then come other for a final time to ensure that all sub modules make sense and thier ideas make sense and are appropriately assigned out.
C++
/*
What function does
PARAMS:
- nameOfVar `type` - Addtional Detals (if applicable)
PROMISES:
- nameOfVar `type` - Additional Details (if applicable)
AUTHOR(S):
- Your Name <<semiperminant@exmaplemail.com>
- Another Example <different@examplemail.com>
semi-permanent email, do not need to respond but try to be a good alumni
*/
int exampleFunct (int inputVar) {
// comments annotate the line below them
int varExamlpe;
// example variable, is strongly typed. Can only be an integer
int varExample1 = 0;
// example function does nothing significant.
return 0;
};
C
/*
What function does
PARAMS:
- nameOfVar `type` - Addtional Detals (if applicable)
PROMISES:
- nameOfVar `type` - Additional Details (if applicable)
AUTHOR(S):
- Your Name <<semiperminant@exmaplemail.com>
- Another Example <different@examplemail.com>
semi-permanent email, do not need to respond but try to be a good alumni
*/
int exampleFunct (int inputVar) {
// comments annotate the line below them
int varExample0;
// exampe variable is strongly typed. In this case can only be an integer
int varExample1 = 0;
// example function does nothing significant
return 0;
};
Java/C#
// these languages is cursed and full of boilerplate
// use anything else if you can
// high memory overhead, use C++ instead
// you can add standard here just make it similar to the rest
Golang
// I dont know
// you can add standard here just make it similar to the rest
Lua
-- I dont know
-- you can add standard here just make it similar to the rest
Terraform
This will probably only used for cloud applications
<!--
I dont know
you can add standard here just make it similar to the rest
-->
HTML
This is the same as any other page, not unique, should still vet in a html validator/best practices author goes in human.txt, for more info please see here
<!DOCTYPE html>
<html>
<head>
<title>Our Funky HTML Page</title>
<meta
name="description"
content="Our first page" />
<meta
name="keywords"
content="html tutorial template" />
</head>
<body>
Content goes here.
</body>
</html>
JSON, YAML, XML, CSS
These are more like data types/file format, follow rules of the language
Bash
Always starts with a shebang
#!
echo "Hello World!"
# I dont know
# you can add standard here just make it similar to the rest
Github Actions
Please find example in any baja repo under .github/workflows/*.yaml
star is a wildcard and in this case represents any name of the file
Do not feel bad using AI for this, but all of these are linux commands for the most part
# name of the workflow.
# this is optional.
name: Cloud Actions
# events that will trigger this workflow.
# here, we only have "pull_request", so the workflow will run
# whenever we create a pull request.
# other examples: [push] and [pull_request, push]
on:
pull_request:
push:
branches:
- master
# each workflow must have at least one job.
# jobs run in parallel by default (we can change that).
# each job groups together a series of steps to accomplish a purpose.
jobs:
# name of the job
ruffLint:
# the platform or OS that the workflow will run on.
runs-on: ubuntu-latest
# series of steps to finish the job.
steps:
# name of the step.
# steps run sequentially.
# this is optionale
- name: checkout
# each step can either have "uses" or "run".
# "uses" run an action written somewhere other than this workflow .
# usually from the community.
# this action checks out the repo code to the runner (instance)
# running the action
uses: actions/checkout@v3
# another step.
# this step runs a bash (Ubuntu's default shell) command
- name: install ruff
run: pip install ruff
- name: Lint
run: ruff check --ignore E402
Dockerhub:
runs-on: ubuntu-latest
needs: ruffLint # will only run if linter is successful
if: ${{ github.ref == 'refs/heads/master' || github.event.pull_request.merged == true }} # Runs if it's a push to 'main' or a merged PR to 'main'
steps:
- name: checkout
uses: actions/checkout@v3
- name: Login to Dockerhub # log into docker hub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_USERNAME }} # Using secret for Docker username
password: ${{ secrets.DOCKER_PASSWORD }} # Using secret for Docker password
id: docker-login
- name: build container image # build the container
run: docker compose build --no-cache
id: docker-build
- name: Upload to Dockerhub
run: docker push darkicewolf50/uofcbajacloud:latest
if: ${{ steps.docker-login.outcome == 'success' && steps.docker-build.outcome == 'success' }}