This question is locked. New answers and comments are not allowed.
Hi,
After having tried JustCode for a month, I whish to share my feedback here.
Context first, why I came across JustCode ?
I tried Resharper and I found it just unusable on real projects and with a standard machine (you know, with a spin disk...).
Second, I disliked its intrusive way to operate.
So I looked for an alike tool, and I found JustCode.
My experience with JustCode
For information, my computer has a legacy disk, 12 GB of RAM, a quad-core CPU. It is far from the top, but it's not the worst configuration. I'm used to have several VS opened (often 2 or 3, sometimes many more). My projects are typically in C#, .NET 3.5 to 4.5 (console and web apps for the most part).
First of all, it's a good but expensive product. It seems clear that there is a lot of work and cleverness behind the tool.
It is far less intrusive than Resharper and a little faster in general.
And I purchased it.
BUT, some annoying things to me makes me not say that it's a great product.
What I disliked
Initial configuration / shortkeys
A thing that I really dislike with ReSharper is it wants to replace all VS default shortkeys!
I like to be able to easily switch on another computer without any tool (just VS with default c# profile settings) and I know that developers accustomed to ReSharper have some difficulty to adapt themselve to a "naked" VS (I saw it). And I do not want to feel like this.
JustCode is way better in this area: there is far less default shortcuts. Nevertheless, after installation, there are some conflicts with default VS shortcut. It's ok if JustCode wants to replace a shortkeys with the same functionality. Otherwise it is not. For example, there are lots of shortkeys for JustCode tests runner. I do not want to use it. So I basically have to uncheck all shortkeys in conflicts with features I did not demanded.
I know it's hard. We all want expose all our features. But think about the user experience: I do not use all VS features, and I do not use all JustCode features. I want to be able to select what I want to pick. And before that, I prefer to stick with default non conflicted settings. Be forced to uncheck a bunch of checkboxes because of conflicts in a First installation Wizard is just borring.
Code style / Naming conventions
I'm used to code several enums in one file named "Enums.cs". And I think I'm not unique in this case.
JustCode generates the warning "Type name does not math file name" for each enum in this file.
There is no smart way to configure an exception to this rule (one type by file).
I definitely can change my habits, but I think that should not be needed with a ("unobtrusive") productivity tool.
Similarily, sometimes I organize some interfaces in a folder named "_interfaces". The underscore means that the folder name is not included in the namespace.
For example:
\Root
\_interfaces
interface1.cs (namespace: Root)
\Commponent
component1.cs (namespace: Root.Component)
On this latter case, I appreciate the answer from the support. There is a pretty useful way to exclude un folder from the namespace rule: select the folder and change its (discrete) property "Do Not Contribute to Namespace".
Naming convention suggestion: rename field and conflict...
If the suggested name the a field to rename is already used, JustCode add a number at the end of the name.
For example:
private static readonly object _instance;
public static object Instance { get { return _instance; } }
--> JustCode wants to rename _instance to Instance, but the actual name will be Instance1.
This is ugly. I think it should not generate any warning in this particular case.
In addition, the field is not always renamed in comments (like "<see cref='typename'/>"). So the code change generates warning from VS compiler.
Generated code
It's pretty common to have some code files that simply can't respect code style rules.
For example, generated code and native method calls (P/Invoke).
Here either, there is no smart way to filter these files from code analysis.
Though, it should be relatively simple to exclude members marked with GeneratedCodeAttribute. I have typically lots of DTO that contains properties named from SQL column names. Theses DTO are marked with GeneratedCodeAttribute and, in my opinion, should be ignored by JustCode because it's not my code. If there is a problem with generated code files, VS compiler is good enough to do its job and warn me.
For P/Invoke, the "recommended way" by MS is to move these calls to a NativeMethods class (so a NativeMethods.cs file). Because it's a convention, JustCode should be smart enough to allow exclusion of this file from code analysis (or coding style rules).
It is possible to exclude files by filename and it's what I've done. But why it's not the default configuration ? ;-)
Refactor
I used "rename field" feature and it seems that JustCode do not take into account conditional compilation constants.
For example:
#if STORE_ALL_FIELDS
const Field.Store noStore = Field.Store.YES;
#else
const Field.Store noStore = Field.Store.NO;
#endif
If a switch STORE_ALL_FIELDS, my project do not compile anymore after a rename of the variable "noStore".
Code cleaning
Add default modifier to declarations without access modifier:
If keyword "sealed" is present, JustCode deletes it (and add the default access modifier). It's a bug (not a feature).
Remove unused using:
JustCode ignores my comments (and specifically <see cref="typename"/>). So it removes using directives, I comments become unresolvable. After the changes, VS compiler warns me about my comments. I think it's a bug, but JustCode perhaps could be smart enough to "detect" new warnings from VS directly created by its changes, and rollback them (and display apologize.... ok ok).
In addition, I liked to see a cleaning rule "remove unnecessary namespaces on type names".
For example:
using MyNamespace;
class MyType {
private MyNamespace.MyType _instance;
}
This example is overly trivial but that rule could help in typical production code.
Performances
All is fine with only one instance of VS and a solution with few projects.
All is not fine with several instance of VS (and some solutions with a dozen of projects - but it's not generalized to all solutions).
Often, when I open more than 2 solutions, I have to deactivate JustCode because it's unusable (sometimes I have to wait seconds between each keystroke).
I noticed that Resharper has some smart mecanism: it waits a delay before refresh after code change (like 300ms). I don't think JustCode has a similar feature. Maybe, it would have helped.
I disabled typing assistance, visual aid tag and smart tags, it's better but there is no miracle...
It's unfortunately the most annoying thing...
Wrong errors/warning
Sometimes, JustCode becomes crazy and generate irrelevant errors and warning. I have to disable it until it calmed down.
Licence activation
I had to uninstall my trial version and reinstall JustCode after purchase to activate my licence. It's not very respectfull to the user experience these days...
Finally, I wish to thanks the team: they seems to be relatively easy to contact.
Thanks for reading,
Eric
After having tried JustCode for a month, I whish to share my feedback here.
Context first, why I came across JustCode ?
I tried Resharper and I found it just unusable on real projects and with a standard machine (you know, with a spin disk...).
Second, I disliked its intrusive way to operate.
So I looked for an alike tool, and I found JustCode.
My experience with JustCode
For information, my computer has a legacy disk, 12 GB of RAM, a quad-core CPU. It is far from the top, but it's not the worst configuration. I'm used to have several VS opened (often 2 or 3, sometimes many more). My projects are typically in C#, .NET 3.5 to 4.5 (console and web apps for the most part).
First of all, it's a good but expensive product. It seems clear that there is a lot of work and cleverness behind the tool.
It is far less intrusive than Resharper and a little faster in general.
And I purchased it.
BUT, some annoying things to me makes me not say that it's a great product.
What I disliked
Initial configuration / shortkeys
A thing that I really dislike with ReSharper is it wants to replace all VS default shortkeys!
I like to be able to easily switch on another computer without any tool (just VS with default c# profile settings) and I know that developers accustomed to ReSharper have some difficulty to adapt themselve to a "naked" VS (I saw it). And I do not want to feel like this.
JustCode is way better in this area: there is far less default shortcuts. Nevertheless, after installation, there are some conflicts with default VS shortcut. It's ok if JustCode wants to replace a shortkeys with the same functionality. Otherwise it is not. For example, there are lots of shortkeys for JustCode tests runner. I do not want to use it. So I basically have to uncheck all shortkeys in conflicts with features I did not demanded.
I know it's hard. We all want expose all our features. But think about the user experience: I do not use all VS features, and I do not use all JustCode features. I want to be able to select what I want to pick. And before that, I prefer to stick with default non conflicted settings. Be forced to uncheck a bunch of checkboxes because of conflicts in a First installation Wizard is just borring.
Code style / Naming conventions
I'm used to code several enums in one file named "Enums.cs". And I think I'm not unique in this case.
JustCode generates the warning "Type name does not math file name" for each enum in this file.
There is no smart way to configure an exception to this rule (one type by file).
I definitely can change my habits, but I think that should not be needed with a ("unobtrusive") productivity tool.
Similarily, sometimes I organize some interfaces in a folder named "_interfaces". The underscore means that the folder name is not included in the namespace.
For example:
\Root
\_interfaces
interface1.cs (namespace: Root)
\Commponent
component1.cs (namespace: Root.Component)
On this latter case, I appreciate the answer from the support. There is a pretty useful way to exclude un folder from the namespace rule: select the folder and change its (discrete) property "Do Not Contribute to Namespace".
Naming convention suggestion: rename field and conflict...
If the suggested name the a field to rename is already used, JustCode add a number at the end of the name.
For example:
private static readonly object _instance;
public static object Instance { get { return _instance; } }
--> JustCode wants to rename _instance to Instance, but the actual name will be Instance1.
This is ugly. I think it should not generate any warning in this particular case.
In addition, the field is not always renamed in comments (like "<see cref='typename'/>"). So the code change generates warning from VS compiler.
Generated code
It's pretty common to have some code files that simply can't respect code style rules.
For example, generated code and native method calls (P/Invoke).
Here either, there is no smart way to filter these files from code analysis.
Though, it should be relatively simple to exclude members marked with GeneratedCodeAttribute. I have typically lots of DTO that contains properties named from SQL column names. Theses DTO are marked with GeneratedCodeAttribute and, in my opinion, should be ignored by JustCode because it's not my code. If there is a problem with generated code files, VS compiler is good enough to do its job and warn me.
For P/Invoke, the "recommended way" by MS is to move these calls to a NativeMethods class (so a NativeMethods.cs file). Because it's a convention, JustCode should be smart enough to allow exclusion of this file from code analysis (or coding style rules).
It is possible to exclude files by filename and it's what I've done. But why it's not the default configuration ? ;-)
Refactor
I used "rename field" feature and it seems that JustCode do not take into account conditional compilation constants.
For example:
#if STORE_ALL_FIELDS
const Field.Store noStore = Field.Store.YES;
#else
const Field.Store noStore = Field.Store.NO;
#endif
If a switch STORE_ALL_FIELDS, my project do not compile anymore after a rename of the variable "noStore".
Code cleaning
Add default modifier to declarations without access modifier:
If keyword "sealed" is present, JustCode deletes it (and add the default access modifier). It's a bug (not a feature).
Remove unused using:
JustCode ignores my comments (and specifically <see cref="typename"/>). So it removes using directives, I comments become unresolvable. After the changes, VS compiler warns me about my comments. I think it's a bug, but JustCode perhaps could be smart enough to "detect" new warnings from VS directly created by its changes, and rollback them (and display apologize.... ok ok).
In addition, I liked to see a cleaning rule "remove unnecessary namespaces on type names".
For example:
using MyNamespace;
class MyType {
private MyNamespace.MyType _instance;
}
This example is overly trivial but that rule could help in typical production code.
Performances
All is fine with only one instance of VS and a solution with few projects.
All is not fine with several instance of VS (and some solutions with a dozen of projects - but it's not generalized to all solutions).
Often, when I open more than 2 solutions, I have to deactivate JustCode because it's unusable (sometimes I have to wait seconds between each keystroke).
I noticed that Resharper has some smart mecanism: it waits a delay before refresh after code change (like 300ms). I don't think JustCode has a similar feature. Maybe, it would have helped.
I disabled typing assistance, visual aid tag and smart tags, it's better but there is no miracle...
It's unfortunately the most annoying thing...
Wrong errors/warning
Sometimes, JustCode becomes crazy and generate irrelevant errors and warning. I have to disable it until it calmed down.
Licence activation
I had to uninstall my trial version and reinstall JustCode after purchase to activate my licence. It's not very respectfull to the user experience these days...
Finally, I wish to thanks the team: they seems to be relatively easy to contact.
Thanks for reading,
Eric
3 Answers, 1 is accepted
0
Accepted
Hello,
Thank you for your detailed feedback.
As a token of gratitude we extended your JustCode license with 1 year - it is now valid till 2016. We also added 2000 Telerik Points to your account.
I will go through your feedback points one by one.
Initial configuration / shortkeys
We do understand that overriding the user shortcuts is extremely annoying. That is why, we have provided a way for the user to be able to choose which shortcuts we can override and which not. We understand your point of just overriding the same functionality. However, there is no easy way to do that. A given shortcut may not point to a default Visual Studio command, but to a command coming from another tool. There is no way for JustCode to know whether this command has the same functionality or not. So the best thing we can do here is to let the user decide. Yes, this slows down the initial setup a bit, but it's really flexible and we never override a shortcut the user does not want us to.
Code style / Naming conventions
I added a feature request for allowing more than one enum inside Enums. You can vote for it here. The top voted items are considered during our planing for the next release.
Naming convention suggestion: rename field and conflict...
The naming convention warning shows you that the field does not follow the convention for private fields in your settings. JustCode shows you how the field would be renamed without considering any possible conflicts with existing members of the type. This is done for performance reasons. In order for us to know whether a conflict could exist, we need to analyze all members of this type plus the ones coming from parent types. And this could slow down the user experience a lot. So we decided to show the possible name of the member after rename. When the fix is executed it does check for conflicts and that is why you get this result in this case.
I could suggest that you add underscore and a prefix for all private fields of a type if this is the naming convention you follow. This way JustCode will not show any warnings.
Generated code
Not showing warnings from constructs having GeneratedCodeAttribute is a nice suggestion and we will consider it.
As for not adding NativeMethods to the default values - we add there only files that we know contain auto generated code. Since "NativeMethods" files are not such files, we decided not to have them as a default since the user could potentially have some issues inside such files, which JustCode could show and fix.
Refactor
Currently, we do not have plans for conditional compilation constants into account. It would be a nice addition, but we prefer implementing more valuable features than this one.
Code cleaning
Add default modifier to declarations without access modifier:
This is indeed a bug, which we have already fixed. The fix will be included in our next internal build.
Remove unused using:
JustCode does not annotate usages inside comments. We have plans for implementing this, however.
As for conversion between fully qualified types and simple types - I have added a feature request. You can vote for it here.
Performances
We are constantly doing performance improvements and try not to get in the user way. I could suggest disabling also the color identifiers and structural highlighting.
Wrong errors/warning
Since JustCode relies on the Visual Studio API it is possible that we sometimes get old or wrong data. That could be the main reason for showing wrong code problems. I could suggest using JustCode -> Analysis -> Refresh Code Analysis in such cases.
Your help is highly appreciated!
If you have any more questions or remarks, do not hesitate to contact us again!
Regards,
Ivan
Telerik
Thank you for your detailed feedback.
As a token of gratitude we extended your JustCode license with 1 year - it is now valid till 2016. We also added 2000 Telerik Points to your account.
I will go through your feedback points one by one.
Initial configuration / shortkeys
We do understand that overriding the user shortcuts is extremely annoying. That is why, we have provided a way for the user to be able to choose which shortcuts we can override and which not. We understand your point of just overriding the same functionality. However, there is no easy way to do that. A given shortcut may not point to a default Visual Studio command, but to a command coming from another tool. There is no way for JustCode to know whether this command has the same functionality or not. So the best thing we can do here is to let the user decide. Yes, this slows down the initial setup a bit, but it's really flexible and we never override a shortcut the user does not want us to.
Code style / Naming conventions
I added a feature request for allowing more than one enum inside Enums. You can vote for it here. The top voted items are considered during our planing for the next release.
Naming convention suggestion: rename field and conflict...
The naming convention warning shows you that the field does not follow the convention for private fields in your settings. JustCode shows you how the field would be renamed without considering any possible conflicts with existing members of the type. This is done for performance reasons. In order for us to know whether a conflict could exist, we need to analyze all members of this type plus the ones coming from parent types. And this could slow down the user experience a lot. So we decided to show the possible name of the member after rename. When the fix is executed it does check for conflicts and that is why you get this result in this case.
I could suggest that you add underscore and a prefix for all private fields of a type if this is the naming convention you follow. This way JustCode will not show any warnings.
Generated code
Not showing warnings from constructs having GeneratedCodeAttribute is a nice suggestion and we will consider it.
As for not adding NativeMethods to the default values - we add there only files that we know contain auto generated code. Since "NativeMethods" files are not such files, we decided not to have them as a default since the user could potentially have some issues inside such files, which JustCode could show and fix.
Refactor
Currently, we do not have plans for conditional compilation constants into account. It would be a nice addition, but we prefer implementing more valuable features than this one.
Code cleaning
Add default modifier to declarations without access modifier:
This is indeed a bug, which we have already fixed. The fix will be included in our next internal build.
Remove unused using:
JustCode does not annotate usages inside comments. We have plans for implementing this, however.
As for conversion between fully qualified types and simple types - I have added a feature request. You can vote for it here.
Performances
We are constantly doing performance improvements and try not to get in the user way. I could suggest disabling also the color identifiers and structural highlighting.
Wrong errors/warning
Since JustCode relies on the Visual Studio API it is possible that we sometimes get old or wrong data. That could be the main reason for showing wrong code problems. I could suggest using JustCode -> Analysis -> Refresh Code Analysis in such cases.
Your help is highly appreciated!
If you have any more questions or remarks, do not hesitate to contact us again!
Regards,
Ivan
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Eric
Top achievements
Rank 1
Rank 1
answered on 21 Jul 2014, 06:03 PM
Thank you so much for the licence extension and for your comprehensive answer.
Initial configuration / shortkeys
I confirm that the setup wizard is well designed. I probably spent around 10 minutes inside, mostly to uncheck shortcuts with conflict. But after that, I didn't had any issue regarding shortcuts.
I'm scarred by a bad experience with ReSharper, especially because I felt I had to use lots of new shortcuts, most of them in conflict with VS. I had a colleague who spoke to me all the time in a "ReSharper keys language".
ReSharper is probably a very good tool, very popular, and I have the impression that, with JustCode, you tried to reach a similar market with another way of thinking. A sort of "lightweight", less intrusive tool. I'm definitely fan of simple tools that "just works" and the "less is more" way of thinking.
To conclude on this, my point was not a real shortcoming but just a thought about this feeling, in my personnal point of view. In my case, I don't have a lot of tools installed in VS. As explained, I like to have a relatively standard workstation to be able to be at ease with any machine other than mine, to be "interoperable". So, the only command I had before JustCode were default commands from VS. I preferred to have to check new functionalities in conflict with default commands rather than uncheck them.
I understand the difficulty to assess different configuration profiles.
I don't have any suggestion to make this better, but my feeling was far from perfect in my given situation. So I noted it :-).
Code style / Naming conventions / Remove unused using
I voted for them, thanks!
Naming convention suggestion: rename field and conflict
I understand the difficulty. With this kind of tool, we become quickly claimant for some intelligence and we forget that it's just a tool. Yet, result of this rename is deceptive. I will adopt your suggestion to avoid this warning.
Generated code
Cool.
NativeMethods
It's right, it could contain user code. But if you don't disable some warnings for that file, I don't understand how it's possible to have useful feedback from JustCode because P/Invoke calls are typically shaped by the naming conventions of native libraries bound. I believe most developers are using http://pinvoke.net/ to copy/past native calls they need. In that sense, I doubt that the most part of this file is ultimately assimilable to user code.
Moreover, I think that some warnings are dangerous to correct: for example, "Field 'SessionID' can be made readonly" in the next sample.
The other alternative I see is that JustCode understand P/Invoke code and take into account the native libraries involved.
The link below is a example of code I have. JustCode generates 50 warnings. Not a chance that I check if some of them are pertinent.
Sample NativeMethods.cs
Performances
I already disabled color identifiers and today I disabled structural highlighting. I will see if it helps.
For your information, I had disabled any extensions in my VS before making my feedback. But today, I discovered a perf issue that was due to VS. With Process Monitor, I realized that I forgot to disable .NET assembly binding log (aka fusion log). Simply opening, modifying and closing an app.config file took around 30 sec to perform (freeze when closing the file in VS), just because of logging all references bindings in a small solution but with lots of references. Maybe it was part of the slowliness I experienced and attributed to JustCode.
Wrong errors/warning
When it happened, I tried to refresh code analysis but it didn't helped. This issue occured 2 times in a month of daily work, and it did not last long (a part of the day because I disabled JustCode for a little while).
Thank you again for your availability.
Eric
Initial configuration / shortkeys
I confirm that the setup wizard is well designed. I probably spent around 10 minutes inside, mostly to uncheck shortcuts with conflict. But after that, I didn't had any issue regarding shortcuts.
I'm scarred by a bad experience with ReSharper, especially because I felt I had to use lots of new shortcuts, most of them in conflict with VS. I had a colleague who spoke to me all the time in a "ReSharper keys language".
ReSharper is probably a very good tool, very popular, and I have the impression that, with JustCode, you tried to reach a similar market with another way of thinking. A sort of "lightweight", less intrusive tool. I'm definitely fan of simple tools that "just works" and the "less is more" way of thinking.
To conclude on this, my point was not a real shortcoming but just a thought about this feeling, in my personnal point of view. In my case, I don't have a lot of tools installed in VS. As explained, I like to have a relatively standard workstation to be able to be at ease with any machine other than mine, to be "interoperable". So, the only command I had before JustCode were default commands from VS. I preferred to have to check new functionalities in conflict with default commands rather than uncheck them.
I understand the difficulty to assess different configuration profiles.
I don't have any suggestion to make this better, but my feeling was far from perfect in my given situation. So I noted it :-).
Code style / Naming conventions / Remove unused using
I voted for them, thanks!
Naming convention suggestion: rename field and conflict
I understand the difficulty. With this kind of tool, we become quickly claimant for some intelligence and we forget that it's just a tool. Yet, result of this rename is deceptive. I will adopt your suggestion to avoid this warning.
Generated code
Cool.
NativeMethods
It's right, it could contain user code. But if you don't disable some warnings for that file, I don't understand how it's possible to have useful feedback from JustCode because P/Invoke calls are typically shaped by the naming conventions of native libraries bound. I believe most developers are using http://pinvoke.net/ to copy/past native calls they need. In that sense, I doubt that the most part of this file is ultimately assimilable to user code.
Moreover, I think that some warnings are dangerous to correct: for example, "Field 'SessionID' can be made readonly" in the next sample.
The other alternative I see is that JustCode understand P/Invoke code and take into account the native libraries involved.
The link below is a example of code I have. JustCode generates 50 warnings. Not a chance that I check if some of them are pertinent.
Sample NativeMethods.cs
Performances
I already disabled color identifiers and today I disabled structural highlighting. I will see if it helps.
For your information, I had disabled any extensions in my VS before making my feedback. But today, I discovered a perf issue that was due to VS. With Process Monitor, I realized that I forgot to disable .NET assembly binding log (aka fusion log). Simply opening, modifying and closing an app.config file took around 30 sec to perform (freeze when closing the file in VS), just because of logging all references bindings in a small solution but with lots of references. Maybe it was part of the slowliness I experienced and attributed to JustCode.
Wrong errors/warning
When it happened, I tried to refresh code analysis but it didn't helped. This issue occured 2 times in a month of daily work, and it did not last long (a part of the day because I disabled JustCode for a little while).
Thank you again for your availability.
Eric
0
Hi,
Thank you for your feedback.
My point about P/Invoke calls was that we could show correct errors (not warnings) and provide the user with fixes for them. If we ignore such files by default, we will not only show any warnings, but errors as well.
Nevertheless, you do have a point and we will consider adding such files by default to our ignore filter.
If you have any more questions or remarks, do not hesitate to contact us again!I
Regards,
Ivan
Telerik
Thank you for your feedback.
My point about P/Invoke calls was that we could show correct errors (not warnings) and provide the user with fixes for them. If we ignore such files by default, we will not only show any warnings, but errors as well.
Nevertheless, you do have a point and we will consider adding such files by default to our ignore filter.
If you have any more questions or remarks, do not hesitate to contact us again!I
Regards,
Ivan
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.