Reverse engineering the Puxing PX888K programming format (3: Patch submission and coding style)

The driver I have written has now been accepted by the CHIRP project repository and while I have made sure that it passes the testing suite of the project, as well as that the code adheres to the pep8 guidelines, now the real trials can begin: Actual use. But until the bug reports start rolling in I'm going to feel invincible for a bit. Click-click.

I may have one or two things to say about pep8 though, mostly regarding the line length limit. After a few levels of indentation it starts to put limits of what one can put in string literals, string literals which may be error messages which one would want to understand, and be able to grep for. The Linux kernel coding style documentation has my back on this, or rather, it's probably fair to say that it's the actual source of my thoughts on the matter.

Another thing I think is detrimental when hard-lining at 80 characters is when calling the same or a similar function a lot of times with slightly altered parameters, such as populating a menu.

From a readability standpoint, I think that something like this (please disregard the lazy table formatting):

func_0(	param00,	param01,	param02	)
func_1(	long_name_param10,	param11,	param12	)
func_2(	param20,	long_name_param21,	param22	)
func_3(	param30,	param31,	long_name_param32	)

...is more readable than this:

func_0(	param00,
	param01,
	param02)
func_1(	long_name_param10,
	param11,
	param12)
func_2(	param20,
	long_name_param21,
	param02)
func_3(	param30,
	param31,
	long_name_param32)

...as long as the functions are related and have similar signatures. The first params are all in the same column, as are the seconds, and so on. But if some of the params are string litterals you will soon be at the end of your line length allowance, especially since you're likely to do it at some level of indentation.
At some point it would make more sense to move the data away from the code, and instead just loop over a two-dimensional array or a map, calling the desired functions. I guess that would be the standard answer to these concerns actually: You are not supposed to have that many magic numbers (or magic strings as it were) in your code! I don't disagree with this, but it does depend on whether or not the rest of the project uses this method.

Another point is how much code can be shown at once, the first example takes four rows of my editor to display, allowing me to see more code above and below it, compared to the second example that requires twelve rows. And this in the days of widescreen monitors too. Of course, if you have one of those tiltable monitors I envy you, although all of the one's I've used have had a narrow enough viewing angle that my left and right eye ended up seeing slightly different colors which irritated me to no end.