Generalized Software Style Guide - Revision history

Mbayyari3 at 16:55, 25 May 2020

2020-05-25T16:55:42Z

2019-03-29T03:03:45Z

2019-02-28T06:48:53Z

2019-02-28T06:46:13Z

2019-02-28T06:46:01Z

2019-02-28T06:44:24Z

2019-02-28T06:43:02Z

2019-02-28T06:21:16Z

2019-02-28T06:06:04Z

2019-02-28T05:44:18Z

@@ Line 220: / Line 220: @@
 === Pointers / References ===
-Pointers should almost never be used. There are very few cases where a reference is not a better idea. References are "basically" the same as pointers without the possibility of nullptr's. If you must, use smart pointers.
+Raw C pointer style should be avoided. Things such as malloc and delete should not be used if possible, there is almost always a better way. Most of the time, a smart pointer will work better in these cases as the ownership is explicit.
 Large data structures or objects should be passed around by reference to save cpu cycles spent copying the data.

@@ Line 42: / Line 42: @@
   <nowiki>ball_init_covariance   = new ConfigDouble(cfg, "VisionFilter/Ball/init_covariance",   100);
-ball_process_noise     = new ConfigDouble(cfg, "VisionFilter/Ball/process_noise",      .1);
+ball_process_noise     = new ConfigDouble(cfg, "VisionFilter/Ball/process_noise",     0.1);
 ball_observation_noise = new ConfigDouble(cfg, "VisionFilter/Ball/observation_noise", 2.0);</nowiki>

← Older revision		Revision as of 06:46, 28 February 2019
Line 1:		Line 1:
−	~~== General ==~~
−
−	~~Any simple optimization is done~~
−
	== Style ==		== Style ==

@@ Line 1: / Line 1: @@
 == General ==
 Any simple optimization is done
@@ Line 292: / Line 291: @@
 In general, if code feels way too complicated for the action that it does, someone most likely has already implemented this in some function somewhere. Feel free to ask older member if it already exists.

@@ Line 8: / Line 8: @@
 Overall, things should be pleasant to look at. If things are hard to read, it's more likely there will be bugs.
 If you can't read it at a glance, it's bad and should be redone so it's clear.
 === Variable / Class Names ===
@@ Line 290: / Line 292: @@
 In general, if code feels way too complicated for the action that it does, someone most likely has already implemented this in some function somewhere. Feel free to ask older member if it already exists.

@@ Line 7: / Line 7: @@
 Overall, things should be pleasant to look at. If things are hard to read, it's more likely there will be bugs.
 === Variable / Class Names ===
@@ Line 92: / Line 93: @@
        previousMeasurements(*VisionFilterConfig::slow_kick_detector_history_length),
        health(*VisionFilterConfig::filter_health_init), cameraID(cameraID) {</nowiki>
 == Comments ==
@@ Line 204: / Line 204: @@
 == Structure ==
-No chances for infinite loops / errors
+=== All new code doesn't have to be accepted ===
 === Private / Public ===
@@ Line 276: / Line 278: @@
 	def test_get_closest_opponent(self):
 		...</nowiki>
 == TODO things ==
 Keep line lengths in check
 All magic numbers are config values or const’s at top of file
 Things are initialized in the constructor in the same order they are defined in the header
 Single responsibility principle is often lacking

@@ Line 124: / Line 124: @@
 Within each group, the includes should be in ABC order.
   <nowiki>#include <vector>
@@ Line 132: / Line 134: @@
 #include "KalmanBall.hpp"
 #include "vision/robot/WorldRobot.hpp"</nowiki>
 == Unit Tests ==