style: apply changes due to pre-commit hooks

IRNAS · Mar 19, 2024 · 5d2ed18 · 5d2ed18
1 parent 610ffe9
commit 5d2ed18
Show file tree

Hide file tree

Showing 17 changed files with 75 additions and 66 deletions.
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -6,21 +6,25 @@ labels: "type: bug"
 assignees: ""
 ---
 
-**Describe the bug**
+#### Describe the bug
 
 <!-- A clear and concise description of what the bug is. -->
 
-**Firmware/Software Version**
+#### Firmware/software version
 
-**Hardware Version**
+<!-- Version where the bug appears. -->
 
-**To Reproduce**
+#### Hardware version
 
-<!-- Steps to reproduce the behavior: -->
+<!-- Hardware version where the bug appears, if relevant. -->
+
+#### Steps to reproduce
+
+<!-- Steps to reproduce the behaviour: -->
 
 <!-- 1. Go to '...' -->
 <!-- 2. Click on '....' -->
 
-**Additional context**
+#### Additional context
 
 <!-- Add any other context about the problem here. -->
diff --git a/.github/ISSUE_TEMPLATE/feature-request.md b/.github/ISSUE_TEMPLATE/feature-request.md
@@ -9,14 +9,18 @@ assignees: ""
 ## Context
 
 <!--- Provide some context why is this feature needed.
-Does it build from an existing feature, does it enable an implementation of some other new feature? -->
+Does it build from an existing feature, does it enable an implementation of some
+other new feature? -->
 
 ## Required steps / Implementation details
 
-<!--- Either provide a list of steps that are required for this feature and/or provide technical details on how this feature will be implemented. -->
+<!--- Either provide a list of steps that are required for this feature and/or
+provide technical details on how this feature will be implemented. -->
 
 ## Definition of Done
 
-<!--- Explicitly define conditions when this feature request is considered done, so it can be reviewed and validated. -->
+<!--- Explicitly define conditions when this feature request is considered done,
+so it can be reviewed and validated. -->
 
-<!-- For example: Described feature is implemented, documented, tested and reviewed. -->
+<!-- For example: Described feature is implemented, documented, tested and
+reviewed. -->
diff --git a/.github/pr-labeler.yaml b/.github/pr-labeler.yaml
@@ -1,4 +1,4 @@
-# Add lables (on the left) to the PRs of specific branches (on the right)
+# Add labels (on the left) to the PRs of specific branches (on the right)
 pull request: feature/*
 release: release/*
 fix: fix/*
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
@@ -1,6 +1,7 @@
-## Description
+# Description
 
-<!--- A summary of the changes that this PR introduces. Provide a relevant motivation and context about this PR or link an issue that provides it. -->
+<!--- A summary of the changes that this PR introduces. Provide a relevant
+motivation and context about this PR or link an issue that provides it. -->
 
 Closes #
 
@@ -12,7 +13,8 @@ Related #
 
 ## Checklist
 
-<!--- Check items that you fulfilled, strikeout the ones that do not apply and write why  -->
+<!--- Check items that you fulfilled, strikeout the ones that do not apply and
+write why  -->
 
 - [ ] My code follows the [style guidelines] as defined by IRNAS.
 - [ ] I have performed a self-review of my code.

diff --git a/app/conf/debug.conf b/app/conf/debug.conf
@@ -16,6 +16,6 @@ CONFIG_ASSERT=y
 # if enabling asserts takes up to much code space, consider enabling these options
 # CONFIG_ASSERT_NO_COND_INFO=y
 # CONFIG_ASSERT_NO_MSG_INFO=y
-# This one shuld be anabled as a last resort, since the file nad location of the assert will not be printed,
-# thus lowering the usefullness of the assert significantly
-# CONFIG_CONFIG_ASSERT_NO_FILE_INFO=y
+# This one should be anabled as a last resort, since the file nad location of the assert will not be printed,
+# thus lowering the usefulness of the assert significantly
+# CONFIG_CONFIG_ASSERT_NO_FILE_INFO=y
diff --git a/boards/arm/custom_nrf52840dk/board.cmake b/boards/arm/custom_nrf52840dk/board.cmake
@@ -1,4 +1,5 @@
 # Copyright (c) 2021 Nordic Semiconductor ASA
+#
 # SPDX-License-Identifier: Apache-2.0
 
 board_runner_args(jlink "--device=nrf52840_xxAA" "--speed=4000")

diff --git a/codechecker_config.yaml b/codechecker_config.yaml
@@ -8,7 +8,7 @@ analyzer:
   - clangsa
   - --enable=guideline:sei-cert
   - --enable=sensitive
-  # Enable ctu for cross translation unit analyis, note that this will take longer
+  # Enable ctu for cross translation unit analysis, note that this will take longer
   # - --ctu
 
 parse:

diff --git a/drivers/CMakeLists.txt b/drivers/CMakeLists.txt
@@ -0,0 +1 @@
+# Empty file
diff --git a/lib/fancy_ztest/tc_util_user_override.h b/lib/fancy_ztest/tc_util_user_override.h
@@ -17,22 +17,22 @@ extern "C" {
 
 #define TEXT_BLACK "[2;30m"
 #define BG_BLACK   "[24;40m"
-#define BG_RED	   "[24;41m"
+#define BG_RED     "[24;41m"
 #define BG_GREEN   "[24;42m"
 #define BG_YELLOW  "[24;43m"
-#define BG_BLUE	   "[24;44m"
+#define BG_BLUE    "[24;44m"
 #define BG_MAGENTA "[24;45m"
-#define BG_CYAN	   "[24;46m"
+#define BG_CYAN    "[24;46m"
 #define BG_WHITE   "[24;47m"
 
-#define BG_BRIGHT_BLACK	  "[4;40m"
-#define BG_BRIGHT_RED	  "[4;41m"
-#define BG_BRIGHT_GREEN	  "[4;42m"
+#define BG_BRIGHT_BLACK   "[4;40m"
+#define BG_BRIGHT_RED     "[4;41m"
+#define BG_BRIGHT_GREEN   "[4;42m"
 #define BG_BRIGHT_YELLOW  "[4;43m"
-#define BG_BRIGHT_BLUE	  "[4;44m"
+#define BG_BRIGHT_BLUE    "[4;44m"
 #define BG_BRIGHT_MAGENTA "[4;45m"
-#define BG_BRIGHT_CYAN	  "[4;46m"
-#define BG_BRIGHT_WHITE	  "[4;47m"
+#define BG_BRIGHT_CYAN    "[4;46m"
+#define BG_BRIGHT_WHITE   "[4;47m"
 
 #define TC_PASS_STR BG_GREEN TEXT_BLACK "PASS" RESET
 #define TC_FAIL_STR BG_RED TEXT_BLACK "FAIL" RESET

diff --git a/samples/renode_example/README.md b/samples/renode_example/README.md
@@ -65,7 +65,7 @@ file, start the machine and execute tests. The tests are defined in the
 
 To run the tests:
 
-```
+```shell
 renode-test test-nrf52840dk.robot
 ```
 
@@ -78,14 +78,14 @@ driver in the Zephyr kernel has a bug in the temperature conversion procedure
 
 This means that if we input the simulated temperature value with:
 
-```
+```shell
 sysbus.twi0.stts Temperature -5.5
 ```
 
 will not get the expected response if we send the below shell command to the
 firmware:
 
-```
+```renode
 uart:~$ sensors get stts751@4a ambient_temp
 
 # Returned response

diff --git a/samples/renode_example/renode/STTS751/README.md b/samples/renode_example/renode/STTS751/README.md
@@ -6,9 +6,9 @@ Phenode. This chip is supported by Zephyr, but is not implemented in Renode.
 Useful inks:
 
 - Renode Writing a new peripheral:
-  https://renode.readthedocs.io/en/latest/advanced/writing-peripherals.html#
+  <https://renode.readthedocs.io/en/latest/advanced/writing-peripherals.html#>
 - LIS2DW12 -
-  https://github.com/renode/renode-infrastructure/blob/master/src/Emulator/Peripherals/Peripherals/Sensors/LIS2DW12.cs
+  <https://github.com/renode/renode-infrastructure/blob/master/src/Emulator/Peripherals/Peripherals/Sensors/LIS2DW12.cs>
 
 Observations during the implementation process:
 

diff --git a/samples/renode_example/renode/nrf52840dk_nrf52840.repl b/samples/renode_example/renode/nrf52840dk_nrf52840.repl
@@ -8,4 +8,4 @@ userButton: Miscellaneous.Button @ gpio0
     invert: true
     -> gpio0@11
 
-stts: Sensors.STTS751 @ twi0 0x4a
+stts: Sensors.STTS751 @ twi0 0x4a
diff --git a/scripts/codechecker-diff.sh b/scripts/codechecker-diff.sh
@@ -22,29 +22,29 @@ mkdir -p codechecker-diffs
 
 for build_dir in "$@"; do
 
-	name=$(jq -r ".name" ${build_dir}/codecheckerfile.json)
-	board=$(jq -r ".board" ${build_dir}/codecheckerfile.json)
-	build_type=$(jq -r '.build_type' ${build_dir}/codecheckerfile.json)
+    name=$(jq -r ".name" "${build_dir}"/codecheckerfile.json)
+    board=$(jq -r ".board" "${build_dir}"/codecheckerfile.json)
+    build_type=$(jq -r ".build_type" "${build_dir}"/codecheckerfile.json)
 
-	# If build_type is null, we don't want to add it to the name
-	if [[ $build_type = null ]]; then
-		build_type=""
-	else
-		build_type="-"$build_type
-	fi
+    # If build_type is null, we don't want to add it to the name
+    if [[ $build_type = null ]]; then
+        build_type=""
+    else
+        build_type="-"$build_type
+    fi
 
-	filename="codechecker-diff-${name}-${board}${build_type}.txt"
+    filename="codechecker-diff-${name}-${board}${build_type}.txt"
 
-	east codechecker servdiff --build-dir ${build_dir} --new >codechecker-diffs/${filename}
+    east codechecker servdiff --build-dir "${build_dir}" --new >codechecker-diffs/"${filename}"
 
-	# A little bit of parsing to get the number of detected errors
-	number_detected_errors=$(sed -nr 's/Number of analyzer reports.*\| ([0-9]+).*/\1/p' codechecker-diffs/${filename})
+    # A little bit of parsing to get the number of detected errors
+    number_detected_errors=$(sed -nr 's/Number of analyzer reports.*\| ([0-9]+).*/\1/p' codechecker-diffs/"${filename}")
 
-	if [[ $number_detected_errors > 0 ]]; then
-		echo "New errors were detected in ${name}"
-		echo "::error ::New errors were detected by the CodeChecker in ${name}-${board}${build_type} build. Click Summary, scroll down to the bottom and download the codechecker-diff file to see the detected errors."
-		error_detected=1
-	fi
+    if [[ $number_detected_errors -gt 0 ]]; then
+        echo "New errors were detected in ${name}"
+        echo "::error ::New errors were detected by the CodeChecker in ${name}-${board}${build_type} build. Click Summary, scroll down to the bottom and download the codechecker-diff file to see the detected errors."
+        error_detected=1
+    fi
 
 done
 

diff --git a/scripts/rpi-jlink-server/request_resource.sh b/scripts/rpi-jlink-server/request_resource.sh
@@ -12,9 +12,9 @@ fi
 timeout="$1"
 interval="$2"
 request_url="$3"
-start_time=$(date +%s)  # Converts the date into unix timestamp
+start_time=$(date +%s) # Converts the date into unix timestamp
 
-echo $start_time
+echo "$start_time"
 
 while true; do
     # Send a POST request to the request_url and capture the HTTP response code

diff --git a/scripts/rpi-jlink-server/twister_pty.py b/scripts/rpi-jlink-server/twister_pty.py
@@ -13,15 +13,16 @@
 HOST = args.host
 PORT = args.port
 
-def read_telnet_output():
 
+def read_telnet_output():
+    """Read the telnet output and print it to the terminal."""
     try:
         with telnetlib.Telnet(HOST, PORT) as tn:
             while True:
-                line = tn.read_until(b'PROJECT EXECUTION SUCCESSFUL')
+                line = tn.read_until(b"PROJECT EXECUTION SUCCESSFUL")
                 print(line.decode("utf-8"))
-                if b'PROJECT EXECUTION SUCCESSFUL'in line:
-                    print(f"Tests finished running. Exiting!")
+                if b"PROJECT EXECUTION SUCCESSFUL" in line:
+                    print("Tests finished running. Exiting!")
                     return 0
 
     except Exception as e:

diff --git a/tests/README.md b/tests/README.md
@@ -6,10 +6,6 @@ framework Ztest and test runner Twister.
 As Zephyr already provides great documentation on this [topic], this document
 will only provide basic instructions, working examples and tips and tricks.
 
-### Test and coverage reports
-
-`makefile` in the root of the project directory has several useful commands
-
 [topic]: https://docs.zephyrproject.org/latest/develop/test/index.html
 
 ## Quick start with the `sample_test` project
@@ -28,7 +24,7 @@ east build -b native_posix -t run
 
 After the build process, you will be greeted with the following output:
 
-```
+```code
 *** Booting Zephyr OS build v3.3.99-ncs1 ***
 Running TESTSUITE sample_test_suite
 ===================================================================
@@ -55,15 +51,15 @@ SUITE PASS - 100.00% [sample_test_suite]: pass = 3, fail = 0, skip = 0, total =
 
 Alternatively you could also just build it and directly run the executable:
 
-```
+```code
 east build -b native_posix
 ./build/zephyr/zephyr.elf
 ```
 
 The created `zephyr.elf` file is just a normal Linux executable. To debug it
 with `gdb` you can run:
 
-```
+```code
 gdb build/zephyr/zephyr.elf
 ```
 
@@ -110,7 +106,7 @@ Ztest framework heavily uses macros to keep the boilerplate code down.
 
 Here is a simple unit test that just checks if variable `a` is equal to `0`.
 
-```
+```C
 ZTEST(my_test_suite, simple_equality)
 {
     int a = 0;

diff --git a/tests/sample_test/CMakeLists.txt b/tests/sample_test/CMakeLists.txt
@@ -30,7 +30,7 @@ target_sources(app PRIVATE ${app_sources})
 # B. Use Kconfig symbol to select the module under test inside the prj.conf.
 #
 # This way is used in this sample_test project. If the Kconfig symbol is not
-# visiable as a menuconfig option (it might only exist in the application source
+# visible as a menuconfig option (it might only exist in the application source
 # dir), can create a Kconfig file and source it from there, for example:
 #
 # rsource ../../app/main/src/some_subsys/some_module/Kconfig