3

One thing I have noticed about when I code is that commenting, logging and writing test cases takes me out of any flow I am in and slows down my coding speed. So I am wondering if I do it too much/more than necessary. If I am using a debug logger, is there such thing as logging TOO much stuff? Also, is there a way to make the output log file color coordinated so that I can easily find issues/places where the value is not what I expect? Also, should I comment everything or just certain places explaining why I do something? Finally, what should I be making test cases for? Is it every single if statement or just every function?

Take this code for example:

def parse_data(raw_):
    # Assume raw is a dict
    parsed_output = dict()
    for i in raw_.keys():
        if i["type"] == "child":
            parsed_output[i] = {"type": "Student"}
        else:
            parsed_output[i] = {"type": "Teacher"}

        if 14 <= i["age"] <= 19:
            parsed_output[i]["division"] = "High School"
        elif 11 <= i["age"] < 14:
            parsed_output[i]["division"] = "Middle School"
        elif i["age"] < 11:
            parsed_output[i]["division"] = "Elementary"
                    else:
            parsed_output[i]["division"] = "Staff"
        parsed_output[i]["name"] = i["name"]

    return parsed_output

Should I add in a logging line after every if saying that it found a Student in High School? Or should I just put a debug line saying the # of People found in raw, and one after that says the number of people found in High School, Middle School, Elementary, and staff? For test cases, should I write one for each if statement in this function, or for the function as a whole? Also, for a function like this, do you have separate files you use as "test data" and expected output? Finally, in this function, should I comment before each of the if blocks what each is looking for, or only comment before the first parsed_output to explain that the reason I created a dict at parsed_output[i] was to avoid an index error?

Gorlan
  • 115
  • 1
  • 9
  • 1
    @KevinMGranger when referring other sites, it is often helpful to point that [cross-posting is frowned upon](https://meta.stackexchange.com/tags/cross-posting/info).. Wrt your misguiding note on broad and opinion questions, see [What goes on Software Engineering (previously known as Programmers)? A guide for Stack Overflow](https://softwareengineering.meta.stackexchange.com/q/7182/31260) – gnat Jul 07 '17 at 22:12
  • Instead of `# Assume raw is a dict` you could `assert isinstance(raw, dict)`. Type-testing is frowned upon in python, but can be helpful in initial coding. Also, lots of DRY around `parsed_output[i]`. Do something like `parsed_output[i] = mydict = {}` right under the **for** loop and you can then do stuff like `mydict["type"]="Student")`. You can finish up with a `logger.debug("parse_data(%s)=>%s" % (raw, parsed_output))` at the very end. For extra credit, look into prettyprint. But, no, too much commenting and logging takes too long to write and makes your code hard to read. – JL Peyret Jul 07 '17 at 22:42

0 Answers0