I am evaluating CodeRush and what I am missing is name convention checking. I have used ReSharper before and it automatically checks names of classes, properties, methods and etc. For example properties name for first uppercase letter.
The default CodeRush settings are available via
DevExpress\Options (Ctrl+Shift+Alt+O)
then
Editor \ CodeStyle \ Identifiers
From this page you can configure Fields, Locals and Parameters.
CodeRush also supports a rich eco-system of plugins.
In your case you'd likely be interested in this StyleNinja Plugin
Related
Context
I'm developing a Microsoft Visual Studio extension, for which I've seen there are:
$projectname$ variable to get the name given to the project,
$safeprojectname$ variable to get the name given to the project with all unsafe characters and spaces replaced by underscore.
Source: https://learn.microsoft.com/en-us/visualstudio/ide/template-parameters?view=vs-2019
For example with project name "Tata yoyo" variables will be:
$projectname$ = "Tata Yoyo SWIG",
$safeprojectname$ = "Tata_Yoyo_SWIG".
The extension I'm building is for SWIG projects that will generate Java from C++, and in this context there is a swig.exe call that, among others, takes the Java package as parameter, for which I want it to be all lower case, but for now it is com.company.$safeprojectname$, then, not necessarily lower case (pointing the obvious: if project name is not lower case, package will not be lower case) and I then have to convert it manually to lower case.
What I'm looking for
From source page above (and other documentation pages) I've already seen there is no $lowercasesafeprojectname$ for example, then if anybody knows a way to do it from a function, script or any other way I would be glad.
Edit: while I want for this purpose a lower case safe project name I still want to keep the original $safeprojectname$, then even if #Ed Dore answer is relevant it is not the solution for me.
In any case, do not hesitate if this is not clear or you want more information.
Thanks
If you implement a custom wizard (IWizard) with your template, you can replace the respective token values in the ReplacementsDictionary passed to your IWizard.RunStarted method, with lowercased equivalents.
Sincerely,
The value side of attributes in HTML were very unreadable, too dark, making it especially hard to disseminate between class names in HTML, when using the dark theme on VS Code.
How do I change it to make reading more comfortable?
p.s. My "Tags" are very limited due to rep, but I'm so sure others have this question.
Here is how to accomplish this particular task.
Introducing [me to] a very useful tool: Inspect Editor Tokens and Scopes
Put cursor in, in this case, a quoted value string.
CNTL + SHIFT + P (open command palette).
Find "Developer: Inspect Editor Tokens and Scopes"
Note the textmate scope(s).
Use property: "editor.tokenColorCustomizations" → "textMateRules" to add new rule.
While I'm doing this directly on values in the JSON of settings - and changing quotes there at a high level, this also works with inheritance, so string.quoted.double.html would override the example shown in this screenshot (which applies to ALL double quoted strings), when editing HTML files. I find this useful for making my lint rules standout too.
What is recommended naming scheme for avro types, so that schema evolution works with backward and forward compatibility and schema imports? How do you name your types? How many Schema.Parser instances do you use? One per schema, one global, or any other scheme?
The namespace / type names don't need a special scheme for naming to address compatibility.
If you need to rename something, that's what aliases are for
From what I've seen, using a parser more than once per schema causes some issues with state maintained by the parser
So technically you have 2 options, each has it's own benefits and drawbacks:
A) do include version identifier into namespace or type name
B) do NOT include version identifier into namespace or type name
Explanation: If you want to use schema evolution, you need not to include version number, as both confluent schema registry and simple object encoding does use namespaces, and uses some sort of hash/modified crc as schema fingerprint. When deserializing bytes, you have to know writer schema, and you can then evolve it into reader schema. These two need not to have same name, as schema resolution does not use namespace or type name. (https://avro.apache.org/docs/current/spec.html#Schema+Resolution) On the otherhand, Schema.Parser cannon parse more than 1 schema, which does have same Name, which is fully qualified type of schema, ie namespace.name. So it depends on your usecase, which one do you want to use, both can be used.
ad A) if you do include version identifier, you will be able to parse both(or all) version using same Schema.Parser, which means, that for example these schemas will be processable together in maven-avro-plugin (sorry I do not remember, whether I tested it in single configuration only, or if I did use multiple configurations also, you have to check it yourself). Another benefit is, that you can reference same type in different versions if needed. Drawback is, that after each version upgrade, the namespace and/or type name changes, and you would have to change imports in project. Schema resolution between writer and reader schema should work, and hopefully it will.
ad B) if you do not include version identifier, only one version could be compiled by avro-maven-plugin into java files, and you cannot have one global Schema.Parser instance in project. Why you would like to have just one global instance? It would be helpful if you don't follow bad&frequest advices to use top-level union to define multiple types in one avsc file. Well, maybe it's needed in confluent registry, but if you don't use that one, you definitely don't have to use top-level union. One can use schema imports, when Schema.Parser need to process all imports first and then finally the actual type. If you use these imports, then you have to use one Schema.Parser instance for each group of type+its imports. It's little bit declarational hassle, but it relieves you from having top-level union, which has issues on its own, and it's incorrect in principle. But if your project don't need multiple versions of same schema accessible at the same time, it's probably better than A) variant, as you don't have to change imports. Also there is opened possibility of composition of schemas if you use imports. As all versions have same namespace, you can pass arbitrary version to Schema.Parser. So if there is some a-->b association in types, one can use v2 b and use it with v3 a. Not sure if that is typical usecase, but it's possible.
I'm using jenkins to build an ant project.
The target names in the build.xml are too verbose.
How can I give the target a more user-friendly name?
For example:
I want to change server_remote_stop to "Stop Server", and server_remote_start to "Start Server" without modifying the target names in build.xml (because this build.xml is used by other programs).
Is this possible?
Yes, it is possible, but you will need to use a different Active Choices parameter type: Reactive Reference Parameter.
Here are the settings that I used:
One active choices parameter named PARAMETER1 with some random server names (AAA, BBB)
One active choices reactive reference parameter, that is watching PARAMETER1, has Choice type as "Formatted HTML", has the Advanced option "Omit value" checked, and the following script:
html ="""
Start Server $PARAMETER1
Stop Server $PARAMETER1
"""
This kind of Formatted HTML is rendered in the UI as HTML, and you can mimic HTML components used in Jenkins, like a select box (you can use a radio, checkbox, etc). What is important is that you return some element whose name is "value" and omit the value field that is automatically created by the plugin (thus the advanced option Omit Value).
Since it is a reactive parameter, you can reference other parameters in your Groovy script as well :-)
Hope that helps,
Bruno
I read this paragraph from the Delphi Tools Site
Changes since the last SVN update are:
Added support for FreePascal-like compile-time $INCLUDE “macros”:
%FILE% and %LINE% insert the current filename and line number into the source
%FUNCTION% inserts the current function name, or class.method name into the source
%DATE% and %TIME% allow inserting the compile date/time
Is there a way we can define macros in DWScript (other than these functions) just like people define macors in excel (using VBscript) in a simple way, where the name of the script will be the name of the function that will be used later, without adding {$Include XXX} in the executed script?
N.B.: I konw this can be done by managing the written script to be saved in a certain file called functions for ex. then save the added function with its name to be used (Add), then the user will write Add(1,2) to get the result; but my boss at work wants it to be something that looks like vbscript in excel.
I'm not sure to understand the question, so I'll list various answers to various possible interpretations...
If you want to declare functions that are implicitly supported by the scripting engine without having to "{$include}" or "uses" them, you can declare them via a TdwsUnit component, and attach it to the script component. If you don't have the "coExplicitUses" option set, they'll be available automatically, and you get design-time support in the IDE.
If you want to add internal functions (that are always there), use one of the RegisterInternalFunction overloads, you can check any of the "dwsXxxxFunctions.pas" units for examples. That's potentially more efficient, but also more cumbersome.
If you want to pre-process custom source-level macros in the source code (ala C's macros), you can use the filters functionality (check the HTML or JS filters as example of how a filter can be implemented).
If you want to react dynamically to "unknown" names, so you can declare them on the spot or bind them to something dynamically, you can use TdwsLanguageExtension.FindUnknownName, that's how the RTTI environment works f.i. (see TRTTIEnvironment in dwsRTTIConnector).
If you want to parse completely custom areas of code in a completely custom way, you can use language extensions too, override ReadInstr and check how asmLib & the JSLibModule do it to support "asm".