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.
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).
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
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