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.
"A source code editor never (sic) makes use of line wrapping"
Codewright does have a facility to do line-wrapping - but I agree that it's not the kind of thing that you'd want to enable as a global option...
Note that a "source code editor" doesn't make use of line wrapping.
But most source code editors just happens to have good editor functions for other files too. But not part of their source code editing features.
What many of them do is supporting source code reformatting.
If being ok with not having syntax highlighting, then it's enough to view files with long text lines using the 'less' program. -S switches between wrapped/unwrapped text.
What almost all code editors have is a way to set a visual right-side margin. Very good for policing the source code. With todays monitors, it may not be optimum to stay at max 80 characters. But the code really should be policed to have a maximum width.
1) You want to see the whole line at the same time. 2) You want to be able to have more than one source file side-by-side. 3) Our eyes are not efficient at reading very long text lines. We have to do a lot of slow and tiresome eye movements. 4) Having a long comment following on the same line as code means that you can't see the code when reading the last part of the comment. 5) Having along source code line just with code and no comments, means the line is too complex to quickly decode in the head.
Sometimes, when getting the responsibility for older code, it really is meaningful to start with reindenting the code and just perform a standard cleanup.
When the code is more readable, it may be time to check data types, variable names etc. And to see if the code should be refactored into more logical pieces.
But maintaining code that is hard to read will result in more hard-to-test bugs.
By the way - I'm personally using:
/* Block-style comment for following code block. A bit * easier than having right-side bracketing. */
At start of file or before a declaration, the comment are instead formatted for Doxygen processing.
/** * \brief * Count number of vovels in a text string. * \param[in] string * Text string to scan for number of vovels. If * NULL, it will be treated as an empty string. * \returns * Numbero of vovels found in the string. * \note * Vovel definitions must be loaded using * \c LoadVovels(const char* language_definitions) * or the default rules for english will be used. */
The left side of the comments will follow the current block indent, while the line length is limited by the configured right-hand margin (displayed but not enforced by the editor).