We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
How does one enable line wrapping in the UVision editor? I am unable to locate a control in the dialogs, and searching the help for "wrap" does not yeild anything related. Thanks.
Raise your hand if you actually use Keil's IDE for code monkeying.
I'll bet most of the serious code-monkeys use a separate text editor. I'll do some tweeks in Keil's IDE, but 99.99999% of the time I'm using:
CodeWright
Now the OP wants to read 'long' comments. Since there is plenty of virticle space, USE IT.
/*------------------------------------------------------------------. ; I use flower-boxes for most all comments. Comments that are long ; ; use multiple lines. I do actually close the End-of-Line using ; ; the semicolon instead of leaving it open like this line does... ; I have a template of various indentations for my flower-boxes, ; ; and naturally I used them for the indentations my code needs. ; '------------------------------------------------------------------*/ /*--------------------------------------------------------------. ; I primarily use these comment flowerboxes as a description of ; ; what the following code is supposed to do, where as in-line ; ; or per-line commenting using /* or // */ are for very specific; ; comments and usually represent a warning or some non-obvious ; ; code-monkey note... the following would be an example... ; '--------------------------------------------------------------*/ if( serial_data_input != NULL ) // serial data is ASCII and NULL is '\0' { Big_Data_Base[ i ] = serial_data_input; } else { /*----------------------------------------------------------. ; Indented block of commenting that could be a very long ; ; and boring story of how EOT and EOL might not exist at all; '----------------------------------------------------------*/ if( serial_data_input == ASCII_EOL ) { Big_Data_Base[ i ] = ASCII_EOT; // change it to End of Transmit /*------------------------------------------------------. ; Notice how all of my flower-boxes are of the same ; ; horizontal width. It means as the nested code gets ; ; deeper, the comment blocks get more vertical space ; ; than they would otherwise normally be. But like you ; ; I prefer reading a comment block in its entirety (SP) ; ; and not have to scroll left and right to get what the ; ; stupid and lame comment is. (Generally speaking there ; ; are no stupid and lame comments, as commenting code is; ; one of the most paramount things about coded-monkeying; ; Which brings up the whole "Lines of Code" metric. I ; ; feel it is a lame metric, as the comments to proper ; ; coding can be worth more than the stupid line of code ; '------------------------------------------------------*/ printf( "WARNING: %d", WARNING_CODE_EOT ); } }
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
I have switched to the form recommended by Jack ganssle:
//------------------------------------------------------------------. // I use flower-boxes for most all comments. Comments that are long // use multiple lines. I do actually close the End-of-Line using // the semicolon instead of leaving it open like this line does... // I have a template of various indentations for my flower-boxes, // and naturally I used them for the indentations my code needs. //------------------------------------------------------------------
the reason is quite simple, with Vince's format you have to correct the trailing seicolons positin for each and every edit of the comment you do, with Jack's you do not need to
Erik
Thanks for trying to help, but it isn't an issue of how one should or should not format one's code. I merely desire read some code that has already been typed/formatted:) My question is only "can word wrap be enabled in UVision, and if so how?". Thanks
Totally agree - boxing the right-hand side is just pure masochism!
Lots of pain to absolutely no gain whatsoever!
OP,
See if you can print the source file and hopefully the software you use to print the file (be it Keil's IDE or some other app), can do the line-wrap for you.
Like we've said, it is in-advisable (sp) to have that as a 'feature' in coding. I doubt if Keil supports line-wrapping source code. I've never even tried to do so. Oh, and YELL AT THE Codemonkey who wrote those long lines. Yes, call that old employee up and yell at him! [I did that once: the guy was so appologetic about the trash code he wrote].
Erik, I am familiar with Jack Ganssle's work. We've spoken on the phone several times. I don't disagree with his style, but I feel that the box looks better, and I shall take the time to reformat any new comments to ensure the box remains. It is just a quirk I have. jack's (and your's) is perfectly valid. By all means I don't want to shove my methods down people's throats, but I do like a nice tidy codemonkey source file. And yes the closing block has been a pain at times, but usually I just rewrite the block when I add or delete something to it. It doesn't take too much time once you are "One with Your Editor." Yes, I know you use CodeWright too. I can't live without it: Brief emulation !!! (I've used Brief since it was made by Underware way back when... prior to that I was a WordStar non-document mode junkie).
Andy,
I disagree. There are benefits: CLEAN and CRISP.
I feel that it doesn't!
To me, it's just unnecessary clutter.
Like Per said, having a maximum line length is a good thing. My end-of-line enclosed box is my little reminder of that.
Since Andy is highly regarded by me, I won't challenge his 'feeling' on the clutter. So be it.
Style can be argued to death with no resolution. My style is my style. I'm sure that you, Andy, have your own, and I'm sure it is excellent too.
I just happen to like my style that I've cultivated over decades. Erik has his, Per has his, I have mine.
Indeed it can - just like "taste" !
"I just happen to like my style"
Oh well - there's no accounting for taste...
;-)
I have a refined palate
A function template...
/* **====================================================================== ** Function_Name ACCESSOR Requirement 3.4.1 **====================================================================== ** ** Function comments ** **---------------------------------------------------------------------- ** ** Parameters Passed: <void> ** Parameters Returned: <void> ** Notes: ** **---------------------------------------------------------------------- */ void Function_Name( void ) { /*------------------------------------------------------------------. ; ; '------------------------------------------------------------------*/ if( Andy != FALSE ) { DO_NOTHING; } }
:-P
ALL FILES/MODULES Start with this header... ALL of them! (The Module Description get replaced with module specific information)
/* ________________________________________________________________________ ****************************************************************************. * | ENVIRONMENT | * Copyright (c) 2010 |------------------------| * ACME Corporation | IDE: Kiel | * 1234 Main Street | Tool: uVision 4 | * Springfield, ST 123456 | Rev: 4.11 MDK-ARM | * (800) 555-1212 Ext. 1234 |------------------------| * | Lang: ANSI "C" | * MODULE NAME filename.ext | Arch: Harvard | * MODULE VERSION 0.00 | Pragmas: None | * | Caveats: None | * APPLICATION [Project Name] | Macros: None | * | Kernel: None | * |------------------------| * | CPU: [processor] | * SRS Document EP 123 v1.00 | CLK: [base MHz ] | * SDRL No. EP 456 v1.01 | PPM: [Osc tol ] | * DRAWING No. DWG-123456 Rev - | MIPS: [ MIPS ] | * | CODE: [code size] | * JOB NUMBER 2010-0404 | xData: [external ] | * WBS ELEMENT -003 | iData: [internal ] | * | bData: [banked ] | *--------------------------------------------------+------------------------| * Environment Notes: | Executables: | * | NAMEIF.HEX (EPROM) | * Capable of being batch-file driven and is not | NAMEIF. (DEBUG) | * dependant upon compiler/assembler/linker | (AOMF debugging) | * brand or version provided the code is built |------------------------| * using ANSI "C" standards and ARM7 core | Make/Support Files: | * directives which contain ANSI "C" Libraries. | | * | ProjX.BAT (cmd line) | * All files required are contained within the | ProjX.LNK (lnk ctrl) | * project directory with the exception of the | | * linked library files. (fix that later) | ProjX.SYM (Symbols) | * | ProjX.MAP (Map file) | * | | *--------------------------------------------------^------------------------' * * MODULE DESCRIPTION: * * Generally "Comments" are either Strategic or Tactical in nature. * While some comments can be categorized as Orientation. * * Strategic comments describe what a section of code is supposed to * accomplish. Strategic comments should be placed before the code * section that implements the task. * * Tactical comments describes the specifics on how the code is * implementing a task. Typically these tactical comments are on an * end-of -line basis. Tactical comments serve to enlighten the * non-obvious behavior or method implemented, and not a re-statement * of what the code performs: * * Orientation and Strategic are closely related, but they do differ. * Orientation comments provide the reader with a wider conceptual view * of the code module. Orientation comments can be information about * the system's environment like the OS, CPU, Memory, IDE, Versions, * etc. While Strategic and Tactical are the dominant forms, * Orientation should be still be contained in all source code modules. * * The over-use of tactical comments will result in source code that * takes too long to read, and begins to devalue and hide the * worth-while comments. Strategic comments should be the primary and * dominant form of commenting source code. * * Tactical comments should be as detailed as needed to inform the * programmer. The common used for Tactical comments is when * describing the side-effects of code implementation or when the code * performs something that is not obvious to the standard or novice * programmer. Always write on a level that is explanatory the reader, * and never assume the reader is as competent as you think you are. * * Tactical comments in "C" typically use the double-slash notation, * while the Strategic comments are flower-boxed. Orientation comments * are typically found at the top of the module. * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * All code meets high relibality standards for the military/aerospace * and automotive industries. The code is compliant with such standards * with only minor exceptions. (e.g. certified" IDEs/tools, and other * practices in which I have deemed should not have been banned, but * merely restricted---like offsetof ) * * Additional levels of the Hi-Rel practices shall be implemented only * if there is a need and/or it is cost effective. * * ---------------------------------------------------------------------- * WARNING - This document contains technical data whose export is * restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751 * et seq.) or the Export Administration Act of 1979, as amended, Title * 50 U.S.C., App 2401 et seq. Violation of these export laws are subject * to severe criminal penalties. Dissemination in accordance with * provisions of DOD Directive 5230.25 (Reference C). * ---------------------------------------------------------------------- * * ===================================================================== * === === === === * === v0.00 === FILE UPDATE AND REVISION HISTORY === 01-Jan-10 === * === === === === * ===================================================================== * * *Version [Description of change] DD-Mmm-YY Author/Engineer *------- -------------------------------------- --------- ----------------- * v0.00 <Original Write> 01-Jan-10 Cpt. Vince Foster * * ___________________________________________________________________________ */
Perfected taste