ReSharper highlights private constants the same as any other unused private entities that are not used in a class. The default settings shows unused entities in light grey text, e.g.:
you can invoke Find Usages on any constant manually in order to find whether it has any usages. Unfortunately, there is no way to do this automatically for a bunch of constants.
yes, but I'm actually not well aware of such a tool.
However, in ReSharper 3.0.3 will contain an experimental weature - solution-wide error analysis which will most likely highlight unused public members.
Yeah I wanted to do it for all public constants. I guess I have to use a tool which finds dead code.
Thanks.
Maybe you could consider making them internal, and I'm not sure, but would a tool like FXCop notice they're unused?
(I've heard one opinion that said public constants are evil, because referencing assemblies actually embed the value compile time rather than looking it up runtime, making it possible that a single constant can actually contain 2 different values within the same application domain)
I don't know of anything that will find unused public entities. The tools I use (ReSharper, Visual Studio Code Analysis, and FxCop) all seem to assume that public entities can be used outside of the assembly. I think this is generally a good assumption to make because entities should be public only if they are to be used outside the assembly; otherwise, I make them internal to the assembly.
What I would like to see in a future release of ReSharper is the ability to highlight a block of entities (fields, properties, methods, whatever) and select Modify Visibility so that I can easily refactor a block of public constants and mark them public, protected, internal, private, or virtual and to highlight a block of constants and turn them into an enumeration.
This is generally how I approach finding and removing dead entities. First I change the accessibility from public to private and recompile the solution. If I get compiler errors, I insert a TODO or other tag and change the accessibility back to public or internal as appropriate (public if it's used outside the assembly or internal if it's used only within the assembly). It's slow and can be very time consuming, but it gets the job done. It would be nice to have a tool automate this, but I suspect there would be a conflict between public entities that are called only from external assemblies versus public entities that are never used (e.g. how do we differentiate the two to eliminate a ton of false positives?).
I think saying "public constants are evil" is somewhat of an understatement. ;)
One of the worst cases I've personally seen was created by a contractor. One particular class was used as a placeholder for literally thousands of constants that prevented any of the members from being strongly typed. I even found several of these constants that were misused and caused a lot of difficult-to-find problems. It took me about a week to refactor the constants into a well-defined set of enumerations and to refactor the properties, fields, and parameters to strongly-typed enumeration types. The overall code wasn't all that bad (thank goodness), but it iis way too easy to pick the wrong constant in an assignment or comparison when these things look almost identical (e.g. using STATE_SUCCESS instead of STATUS_SUCCESS by mistake).
I'm not saying constants are always evil, but I pretty much restrict constants to private values within a class to eliminate magic numbers and magic strings.
>> Yeah I wanted to do it for all public constants. I guess I have to use a >> tool which finds dead code. >> >> Thanks. >
Maybe you could consider making them internal, and I'm not sure, but would a tool like FXCop notice they're unused?
>
(I've heard one opinion that said public constants are evil, because referencing assemblies actually embed the value compile time rather than looking it up runtime, making it possible that a single constant can actually contain 2 different values within the same application domain)
'Assume all code in this project/solution is only used in this solution'
Such an assumption would make it possible to find all unused public and protected members, and very easy to highlight dead code.
Generally when working on custom software most of it doesn't get reused anyway, and cleaning your 'predecessors' projects would become so much easier :)
Best Regards,
Wiebe Tijsma
Lothan wrote:
I don't know of anything that will find unused public entities. The tools I use (ReSharper, Visual Studio Code Analysis, and FxCop) all seem to assume that public entities can be used outside of the assembly. I think this is generally a good assumption to make because entities should be public only if they are to be used outside the assembly; otherwise, I make them internal to the assembly.
What I would like to see in a future release of ReSharper is the ability to highlight a block of entities (fields, properties, methods, whatever) and select Modify Visibility so that I can easily refactor a block of public constants and mark them public, protected, internal, private, or virtual and to highlight a block of constants and turn them into an enumeration.
This is generally how I approach finding and removing dead entities. First I change the accessibility from public to private and recompile the solution. If I get compiler errors, I insert a TODO or other tag and change the accessibility back to public or internal as appropriate (public if it's used outside the assembly or internal if it's used only within the assembly). It's slow and can be very time consuming, but it gets the job done. It would be nice to have a tool automate this, but I suspect there would be a conflict between public entities that are called only from external assemblies versus public entities that are never used (e.g. how do we differentiate the two to eliminate a ton of false positives?).
'Assume all code in this project/solution is only used in this solution'
>
Such an assumption would make it possible to find all unused public and protected members, and very easy to highlight dead code.
>
Generally when working on custom software most of it doesn't get reused anyway, and cleaning your 'predecessors' projects would become so much easier :)
>
Best Regards,
>
Wiebe Tijsma
>
Lothan wrote:
>> I don't know of anything that will find unused public entities. The tools >> I use (ReSharper, Visual Studio Code Analysis, and FxCop) all seem to >> assume that public entities can be used outside of the assembly. I think >> this is generally a good assumption to make because entities should be >> public only if they are to be used outside the assembly; otherwise, I >> make them internal to the assembly. >> >> What I would like to see in a future release of ReSharper is the ability >> to highlight a block of entities (fields, properties, methods, whatever) >> and select Modify Visibility so that I can easily refactor a block of >> public constants and mark them public, protected, internal, private, or >> virtual and to highlight a block of constants and turn them into an >> enumeration. >> >> This is generally how I approach finding and removing dead entities. >> First I change the accessibility from public to private and recompile the >> solution. If I get compiler errors, I insert a TODO or other tag and >> change the accessibility back to public or internal as appropriate >> (public if it's used outside the assembly or internal if it's used only >> within the assembly). It's slow and can be very time consuming, but it >> gets the job done. It would be nice to have a tool automate this, but I >> suspect there would be a conflict between public entities that are called >> only from external assemblies versus public entities that are never used >> (e.g. how do we differentiate the two to eliminate a ton of false >> positives?). >> >> "abdu" <no_reply@jetbrains.com> wrote in message >> news:15049423.1188450636135.JavaMail.itn@is.intellij.net... >>> In my case, these are public constants in a class on their own. >>
ReSharper highlights private constants the same as any other unused private entities that are not used in a class. The default settings shows unused entities in light grey text, e.g.:
private const int TEST = -1;
"abdu" <no_reply@jetbrains.com> wrote in message news:9775179.1188429773178.JavaMail.itn@is.intellij.net...
Attachment not added (content type not allowed): "att1.html"
In my case, these are public constants in a class on their own.
Hello abdu,
you can invoke Find Usages on any constant manually in order to find whether
it has any usages. Unfortunately,
there is no way to do this automatically for a bunch of constants.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Yeah I wanted to do it for all public constants. I guess I have to use a tool which finds dead code.
Thanks.
Hello abdu,
yes, but I'm actually not well aware of such a tool.
However, in ReSharper 3.0.3 will contain an experimental weature - solution-wide
error analysis which will most likely highlight unused public members.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
abdu wrote:
Maybe you could consider making them internal, and I'm not sure, but
would a tool like FXCop notice they're unused?
(I've heard one opinion that said public constants are evil, because
referencing assemblies actually embed the value compile time rather than
looking it up runtime, making it possible that a single constant can
actually contain 2 different values within the same application domain)
Best Regards,
Wiebe Tijsma
I don't know of anything that will find unused public entities. The tools I
use (ReSharper, Visual Studio Code Analysis, and FxCop) all seem to assume
that public entities can be used outside of the assembly. I think this is
generally a good assumption to make because entities should be public only
if they are to be used outside the assembly; otherwise, I make them internal
to the assembly.
What I would like to see in a future release of ReSharper is the ability to
highlight a block of entities (fields, properties, methods, whatever) and
select Modify Visibility so that I can easily refactor a block of public
constants and mark them public, protected, internal, private, or virtual and
to highlight a block of constants and turn them into an enumeration.
This is generally how I approach finding and removing dead entities. First I
change the accessibility from public to private and recompile the solution.
If I get compiler errors, I insert a TODO or other tag and change the
accessibility back to public or internal as appropriate (public if it's used
outside the assembly or internal if it's used only within the assembly).
It's slow and can be very time consuming, but it gets the job done. It would
be nice to have a tool automate this, but I suspect there would be a
conflict between public entities that are called only from external
assemblies versus public entities that are never used (e.g. how do we
differentiate the two to eliminate a ton of false positives?).
"abdu" <no_reply@jetbrains.com> wrote in message
news:15049423.1188450636135.JavaMail.itn@is.intellij.net...
I think saying "public constants are evil" is somewhat of an understatement.
;)
One of the worst cases I've personally seen was created by a contractor. One
particular class was used as a placeholder for literally thousands of
constants that prevented any of the members from being strongly typed. I
even found several of these constants that were misused and caused a lot of
difficult-to-find problems. It took me about a week to refactor the
constants into a well-defined set of enumerations and to refactor the
properties, fields, and parameters to strongly-typed enumeration types. The
overall code wasn't all that bad (thank goodness), but it iis way too easy
to pick the wrong constant in an assignment or comparison when these things
look almost identical (e.g. using STATE_SUCCESS instead of STATUS_SUCCESS by
mistake).
I'm not saying constants are always evil, but I pretty much restrict
constants to private values within a class to eliminate magic numbers and
magic strings.
"Wiebe Tijsma" <wiebeREMOVE@CAPITALStijsma.com> wrote in message
news:fb6o47$fsc$1@is.intellij.net...
>> Yeah I wanted to do it for all public constants. I guess I have to use a
>> tool which finds dead code.
>>
>> Thanks.
>
>
>
>
Hi Lothan,
I think it's a good idea.
What about an option in R# like:
'Assume all code in this project/solution is only used in this solution'
Such an assumption would make it possible to find all unused public and
protected members, and very easy to highlight dead code.
Generally when working on custom software most of it doesn't get reused
anyway, and cleaning your 'predecessors' projects would become so much
easier :)
Best Regards,
Wiebe Tijsma
Lothan wrote:
>> In my case, these are public constants in a class on their own.
I like the idea of that solution-based option.
I have many solutions where that would be true, and it would be really nice
to be able to easily find dead code or unused/obsolete calls, etc.
I also have many solutions where that is definitely NOT true, and would
certainly want to turn it off.
"Wiebe Tijsma" <wiebeREMOVE@CAPITALStijsma.com> wrote in message
news:fbjalc$jus$1@is.intellij.net...
>
>
>
>
>
>
>
>
>> I don't know of anything that will find unused public entities. The tools
>> I use (ReSharper, Visual Studio Code Analysis, and FxCop) all seem to
>> assume that public entities can be used outside of the assembly. I think
>> this is generally a good assumption to make because entities should be
>> public only if they are to be used outside the assembly; otherwise, I
>> make them internal to the assembly.
>>
>> What I would like to see in a future release of ReSharper is the ability
>> to highlight a block of entities (fields, properties, methods, whatever)
>> and select Modify Visibility so that I can easily refactor a block of
>> public constants and mark them public, protected, internal, private, or
>> virtual and to highlight a block of constants and turn them into an
>> enumeration.
>>
>> This is generally how I approach finding and removing dead entities.
>> First I change the accessibility from public to private and recompile the
>> solution. If I get compiler errors, I insert a TODO or other tag and
>> change the accessibility back to public or internal as appropriate
>> (public if it's used outside the assembly or internal if it's used only
>> within the assembly). It's slow and can be very time consuming, but it
>> gets the job done. It would be nice to have a tool automate this, but I
>> suspect there would be a conflict between public entities that are called
>> only from external assemblies versus public entities that are never used
>> (e.g. how do we differentiate the two to eliminate a ton of false
>> positives?).
>>
>> "abdu" <no_reply@jetbrains.com> wrote in message
>> news:15049423.1188450636135.JavaMail.itn@is.intellij.net...
>>> In my case, these are public constants in a class on their own.
>>