.:: Bots United ::. - View Single Post

TomTom · **Re: What are the best practices? -** 15-07-2008

I like there to be lots of comments in code, I just don't like them cluttering up the lines too much (you can always indent end of line comments to keep them away but some editors don't do wide, and it always screws the printing on paper.) What I have wanted was an editor that interpreted the comments and selectively printed/displayed them. Say after each comment was an "escape" character that described the importance of the comment say //\1 could mean level one comment and //\3 would mean level 3 comment. The editor would only show the comments above a settable level and would color the "escape" character to be almost invisible. ( Codewright had lots of programmability but I doubt it could handle that). And if it could handle hyperlinks in comments then lots of documentation could be in a separate file.

Constant coding is very important but bosses rarely do more than lip service. I worked for a company that at one point hired 1 student on work study for every 1.5-2 permanent coders. Absolute mess, the students declared variables wherever they cared to, used Proposed ANSI C styles that the older compilers could not support. They never spent time on the coding style documents, did not know a linker, linker command file or map file from a hole in the ground.

On your embedded point, sprintf is important printf is not in my experience, and you need one of the smaller libraries that can be split up if you have to squash memory. Of course format strings are dangerous in embedded, you can leak and not know it in C so easily (Wolfenstein ET is a good leaky game coded in C). Mind you TI code composer studio had a neat way to output a printf for debugging. They put an index and parameters in 1-4? 32 bit words in memory, then using the idle manager time the pod would pick up the data then match the index up with the constant string in your printf then format and print that string on the debugging PC. No need to format in the target that way.

Don't you mean Verilog should not be treated as C, which it shouldn't...

	(#15)
TomTom ET Waypointing team member Status: Offline Posts: 745 Join Date: Jun 2006	Re: What are the best practices? - 15-07-2008 I like there to be lots of comments in code, I just don't like them cluttering up the lines too much (you can always indent end of line comments to keep them away but some editors don't do wide, and it always screws the printing on paper.) What I have wanted was an editor that interpreted the comments and selectively printed/displayed them. Say after each comment was an "escape" character that described the importance of the comment say //\1 could mean level one comment and //\3 would mean level 3 comment. The editor would only show the comments above a settable level and would color the "escape" character to be almost invisible. ( Codewright had lots of programmability but I doubt it could handle that). And if it could handle hyperlinks in comments then lots of documentation could be in a separate file. Constant coding is very important but bosses rarely do more than lip service. I worked for a company that at one point hired 1 student on work study for every 1.5-2 permanent coders. Absolute mess, the students declared variables wherever they cared to, used Proposed ANSI C styles that the older compilers could not support. They never spent time on the coding style documents, did not know a linker, linker command file or map file from a hole in the ground. On your embedded point, sprintf is important printf is not in my experience, and you need one of the smaller libraries that can be split up if you have to squash memory. Of course format strings are dangerous in embedded, you can leak and not know it in C so easily (Wolfenstein ET is a good leaky game coded in C). Mind you TI code composer studio had a neat way to output a printf for debugging. They put an index and parameters in 1-4? 32 bit words in memory, then using the idle manager time the pod would pick up the data then match the index up with the constant string in your printf then format and print that string on the debugging PC. No need to format in the target that way. Don't you mean Verilog should not be treated as C, which it shouldn't...