| Author |
 Topic  |
|
|
msew
Ketchup Master
94 Posts |
 Posted - Feb 24 2006 : 5:08:49 PM
|
There is an option to display Local Symbols In Bold. I would like to have the option to display Member Symbols in Bold. So now you have a function which has a lot of local symbols and then places where you are actually affecting objects are in bold.
The thought is: bold usually means "this is important" and when you actually modify an object that is important. So that should be bold and not the local symbols.
So having another Environment->Fonts and Colors->Attributes option of: "Member Symbols in Bold" would be great!
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Feb 25 2006 : 10:34:01 AM
|
do you not have a standard naming convention for class member variables? in C++ a lot of people (perhaps even most) use m_ at the start of all member variables, to address this very need. in C# it seems to be common to just place _ at the front of the member variables.
this is why there is the VA option:
VA Options -> text editor -> C/C++ -> insert _ after m and shift
|
zen is the art of being at one with the two'ness |
 |
|
|
alextooter
Ketchup Master
55 Posts |
Posted - Feb 26 2006 : 02:35:38 AM
|
| Maybe Not everyone like MS's style. ^_^ |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Feb 26 2006 : 09:56:52 AM
|
true. thinking about this, if local variables are bold, and all variables are in a custom colour, then any variable that is not bold must be either a global variable or a class member variable.
personally i try to avoid global variables, or i give them distinct names if i do have to use them, for these very reasons. naming conventions can be a very personal thing with strong opinions. |
zen is the art of being at one with the two'ness |
|
|
|
msew
Ketchup Master
94 Posts |
Posted - Feb 27 2006 : 08:12:34 AM
|
true. thinking about this, if local variables are bold, and all variables are in a custom colour, then any variable that is not bold must be either a global variable or a class member variable.
Right and I would prefer the reverse :-) Bold means watch out / be aware. Which is exactly what you should be doing if you are modifying something that can affect others. |
Edited by - msew on Feb 27 2006 08:14:30 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Feb 27 2006 : 3:34:17 PM
|
| that makes sense. but then what about global variables? three options, one for making each type of variable bold is not really an ideal plan, since we try to keep the number of options as small as possible. |
zen is the art of being at one with the two'ness |
|
|
|
jpizzi
Tomato Guru
USA
642 Posts |
Posted - Feb 27 2006 : 11:12:28 PM
|
| Perhaps you could extend the color selection to include bold. That way, you would be enabling the desired behavior without tremendously complicating the options. Along the same lines, you could also allow the choice of italics, for those who desire something other than "stable symbols in italics." |
Joe Pizzi |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Feb 28 2006 : 11:41:12 PM
|
We have considered more options, and dabbled with many ourselves over the years. Generally, we have found too many colors and attributes make code impossible to decipher. This isn't to say the suggestions in this thread don't have merit -- we're just saying we're really careful about doing too much.
We generally prefer VA X to work at install, without need for setting of options. |
|
|
|
msew
Ketchup Master
94 Posts |
Posted - Mar 04 2006 : 01:15:09 AM
|
| local VS global / member works for me. The message of bold means: be aware. When you modify global or member you should be more aware than modifying locals. If you then need to go and look at the specific "bolded" var to see where it is. That is fine. |
|
|
|
msew
Ketchup Master
94 Posts |
Posted - Mar 04 2006 : 01:17:55 AM
|
> We generally prefer VA X to work at install, without need for setting of options.
I would ammend that statement to be: VA X should work at install and have decent defaults, but have some depth for more advanced users / people who use it a lot. c.f. this thread on what xemacs gives you: http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=3193&SearchTerms=emacs |
|
|
|
Damir
Senior Member
Canada
34 Posts |
Posted - Jun 23 2011 : 09:58:25 AM
|
I agree 100% with msew and would like to request this option as well. The point about using prefix conventions (m_ for member variables, g_ for globals, etc) is moot. Personally I do name my variables (in C++) this way, but in professional environment one has to work with the code that others wrote.
Over the years of using VA, I always liked the 'bold' option, but I always wished it worked in reverse to underscore the fact that object's members or globals are being modified.
The current option as is does help, but I have to deal with seeing pretty much everything in bold. By the way in another related topic a poster mentions the same thing. I got used to this, but would like to see this work in reverse to quickly spot important things as msew pointed out. |
Edited by - Damir on Jun 23 2011 09:59:28 AM |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jun 24 2011 : 7:04:03 PM
|
This all is not as a simple problem as you might suppose. The main problem is that the coloring code which decides the color for every single word should be extremely fast to be able to cope with fast scrolling, like when you drag the scollbar. So Visual Assist do not have time to deeply analyze the context for every word. That means if you use the very same symbol name for very different purposes then the coloring code may not be able to help, especially with more complex context. Personally, the first letter of my members is capital, while this is not true for locals, so I can distinguish them. But I agree: sometimes you have to deal with codes that been written by others.
Anyway, a theoretical question: considering we don't prefer adding more different coloring and formatting options, wouldn't it beneficial to just replace the current method with one that distinguish member and locals, rather than symbols that was defined in the same file (current approach). I mean if it would be feasible.  |
|
|
| |
Topic |
|
Member Symbols In Bold
