Just found StyleCop, looks like something worth using for my projects. Then I found out you could use it with ReSharper (a tool I've also never used). So I downloaded ReSharper, as well as StyleCop for ReSharper. I'm just a bit confused about it, though:
With just StyleCop installed (no ReSharper), I get yelled at for referring directly to private variables in code-behind. It wants me to instead do this.variable. Alright, fine.
If I use just ReSharper, it tells me to remove all of the 'this' calls I just added. Which one is better?
If I use ReSharper + StyleCop for ReSharper, it now tells me to add 'this' to all private member references (just like StyleCop did all by itself). However, now it also wants me to add 'this' to all of the controls I'm referencing from the .aspx page (i.e., Label.Text = this.variable -> this.Label.Text = this.variable).
I'm so confused. What is the best standard to follow? Or am I just fine doing it the way I am now (Label.Text = variable)?
The key point is consistency. Your particular formatting with regard to this point comes down to personal preference.
Does the extra wordiness provide additional clarity as to which variable you're referencing or does it obscure the meaning by flooding the page with extra text?
This is a judgment call. They do enforce other rules that make sense; however, a large part of what they do is enforce consistency. As #Martin said, feel free to disable rules that don't make sense for your workflow.
Sorry when working on a team it all comes down to understanding the politics; after all, we work to get paid!
If the person that decided your next
pay raise uses StyleCop, then you
should always include the “this.”
likewise if the boss uses ReSharper
you should do what ReSharper says.
There are a lot more important wars to win this, e.g. 10,000 line classes, over sized method
If you are luckly enough to decide what tools (and coding standards) are used yourself, then I would just choose ReSharper and read the “clean code” book.
I think it's up to you which conventions you want to follow (it's a matter of personal preferences). At least in ReSharper, you can edit the rules to no longer show certain warnings/hints.
Related
I am trying to make changes to the behavior of a function and print the results to a file. The ViewCfg plug-in described in the Plug-in Development Guide does something similar, but I am trying to avoid having to use Ast.get, which ViewCfg uses. I am thinking of extending Printer.extensible_printer which, according to the Frama-C API Documentation, is something I can do if I want to obtain a custom pretty-printer.
However, if I extend the pretty-printer as described in the API docs, unless I'm doing something wrong, I notice that the changes I make take place regardless of which project is set as the current project. I'm using File.create_project_from_visitor to create a new project and Project.set_current to set the new project as the current project before I use the custom pretty-printer.
Is it true that any change made by a class that extends Printer.extensible_printer applies to all projects? I happen to be using frama-c-Aluminium-20160502, which I know is not the latest version.
EDIT: Sorry, I should have made this clearer in the beginning, but I'm not actually making changes to the behavior of a function. I'm reading in the behavior of a function, then based on that, I'm trying to generate as output valid C code that's meant to be read as input by another program.
Regarding AST.get, the only reason I was avoiding it was that it sounds like it gets the entire AST, while I'm only interested in part of it, i.e. behaviors. But if I'm just making things harder for myself by avoiding it, then I'll go ahead and use it.
Within a DWT Template Building Block, we can use a few "free" variables such as ##Component.Title## or ##Component.ID## as well as built-in DWT functions.
I didn't realize we can also get a component's schema description with ##Component.Description## or ##Description##.
The out-of-the-box Default Dreamweaver Component Design has a good set of examples, along with the Tridion Cook book's iteration example, and SDL Live Content.
How else could I find other allowed built-in DWT functions and variables, programmatic or otherwise?
In other words, I wouldn't have thought ##Description## was even available in DWT without seeing an example first (not that I have a use for it yet).
Edit (June 8, 2013): I did find additional information on SDL Live Content (requires login). We can of course use available Package variables as described in the documentation.
Researching a bit, I found that if we go to the tridion.contenmanager.config file, we will discover the node, which references to the Dreamweaver mediator type:
<mediator matchMIMEType="text/x-tcm-dreamweaver" type="Tridion.ContentManager.Templating.Dreamweaver.DreamweaverMediator" />
This namespace can be found inside Tridion.ContentManager.Templating.dll
Decompiling is the best way to find out what is inside and learn something. Since it is .Net code, that will not be a problem, there is many free good tools available. I'm using lately JustDecompile
I did not go too deep into the code, but I can see that there is a TridionObjectSource class, with a number of Constants for reserved words, like:
ReservedNameTitle
ReservedNameDescription
Searching where this constants are used on the code, can help to better understand what they do, and the way the Dreamweaver Mediator works inside.
Seems like an interesting learning exercise
I take it that you've searched the documentation for the answer and come up empty. I suggest that you go to the relevant part of the LiveContent documentation and add a comment. This will reach the documentation team directly, and I'm sure they'll be very interested to hear of a feature that isn't properly covered. With a bit of luck they'll update it, and you'll have done us all a favour.
I have some sympathy for the "help yourself" approach too, but if you find a feature by your own analysis of the software, and it gets removed in a later release, you won't have a leg to stand on to complain about this. So help Tridion to get the feature documented, and then it's there to use with confidence.
I'm looking at requiring my team to document their code more thoroughly for some major upcoming projects and to make life a little less painful, I am steering towards XML documentation generators such as Sandcastle, Doxygen or Box Live Documenter.
What are the key considerations I should keep in mind when evaluating the best option and what experiences have led you to a particular decision?
For me the key considerations would be:
Fully automated: Can it be set up in such a way so that pretty much
no outside work is required to
create or edit the documentation.
Fully styled: Can the documentation be fully styled so
that it looks great in a wiki or pdf
after it’s generated. I should be
able to change colors, font sizes,
layouts, etc.
Good Filtering: Can I select only the items I want to be
generated. I should be able to
filter the namespaces, file types,
classes, etc.
Customization: Can I include headers, footers, custom elements,
etc.
I found Doxygen could do all of this. Our workflow is as follows:
Developer makes a change to the code
They update the documentation tags right above the code they just changed
We click a generate button
Doxygen will then extract all the XML documentation from the code, filter it to only include the classes and methods we want, and apply the CSS styling we’ve pre-made for it. Our end result is an internal wiki that looks the way we want, and doesn’t require editing.
Extra: We have all our projects in various git repositories. We pull all these down to one root folder and generate the docs form this root folder..
Would be interested to know how others are automating even further..?
Who is paying for the documentation and why? (is the system stable enough, does it add enough value)
Who is going to read it, and why is she not using a more effective communication channel?
(if correct mostly distance in time/place)
Who is going to keep it up to date.
When are you going to destroy it? (Automatically if it hasn't been read or updated in the past three months?)
I mostly prefer better code to make my life less painful, over more documentation, but I like scenario & unit tests and a high level architecture description.
[edit] Documentation costs time and money to write and keep up to date. JavaDoc style documentation has a serious detrimental effect on the amount of code simultaneously visible and might be a good idea for the developers using the code, but not for those writing it.
Recently we started using some code names for several different types of prototype applications all following a theme. This made things a little more fun and was a great idea.
The problem is that Im not too sure how people deal with migrating a codebase from "codename" state into version 1.0 state which may have a proper name... not something that a client really shouldnt see :)
We are using Visual Studio at the moment, and I can see that you can change the assembly name, but there are references to the namespaces, etc... that would really be a large change to make.
Do people bother changing things like namespaces before the v1.0 release?
I prefer to change all references including project names, folders, namespaces, everything whenever the real name changes. It can be a bit of a pain, but it's better in the long run, especially when new developers are introduced to a project and are not familiar with the history.
Some companies continue to use code names internally even after the real name is decided and released. Even today there are some places where "Opus" shows up in reference to Microsoft Word (when digging into window handle info, not any published api or ui).
If you keep code names around, you end up with a mess and a large document to have to know what is what.
http://en.wikipedia.org/wiki/List_of_Microsoft_codenames
I've always considered development names to live in a different space than the deliverable product name. Unless the development name is profane, or you are producing libraries or APIs, I don't see necessary harm from the development name appearing in a symbol table or sumptin'. (Your customers will generate their own profanities for your code, anyway ;)
Sam's answer sort of agrees with this stance, if the development names never got outside the code pit, there wouldn't be a Wikipedia page listing them.
Over the past three weeks, I have lost at least 120 man hours because of some lesser known functionality in ActionScript 3. One of the problems was that, with Internet Explorer, if there are too many messages sent through LocalConnections, it will slow the messages sent through, but in the standalone player and in Firefox, this threshold is significantly higher. Another was that the static values of a class are instantiated even if the member itself is not being used:
import path.to.FooClass;
private function thisIsNeverCalledButItEnsuresThatFooClassIsImported():void
{
var f:FooClass = new FooClass();
}
Since FooClass had a static reference to a Singleton, that Singleton was instantiated so when I loaded a Module which used that Singleton, it would bind to values in an unpredictable way.
Additional cases where things behave in an unexpected way:
MovieClip.addFrameScript
flash.trace.Trace as a class
int is a faster incrementer class, Number is faster for mathematics, and uint is incredibly slow.
PrintDataGrid, if it has only one page, needs to have an empty value appended to the end of its dataProvider
If you use try...catch around two LocalConnections and connect them to the same channel, you will force garbage collection without needing System.gc
So here's the question (and I'm sorry for omitting this in the original post), is there any consolidated documentation for this type of behavior anywhere? Is there any (even non-Adobe) documentation on these issues (websites, forums, books, ANYTHING)? I know that these things are definitely easy enough TO document, but has anyone done so?
If not, am I missing anything? Are there other issues which I should know about?
This kind of useful information is very often not "centralized". Moreover, what you are looking for is something related to the experience of the programmer (more than to official docs).
FYI, there are two other methods for ensuring a class is included.
#1 - This syntax is actually used in the Flex source code:
import path.to.FooClass; FooClass; // note double reference
public class References
{
// No references needed in this class
}
#2 - Use the includes command line argument
-includes path.to.FooClass
You can always submit your experience using the "feedback" section in the help. Unfortunately, this is less obvious than the link that used to be at the bottom of each page in the older help files (which also served the useful function of opening a browser window with the web version of that help page).
Adobe says that it incorporates the comments from previous versions of the help into new versions, but my own observation suggests that there are instances where it does not happen. However, that and the appropriate cookbook are still the best avenue for those who believe that this kind of information should be centralized.
Note that the whole purpose behind modules is to avoid compiling code multiple times, so importing FooClass kind of defeated the purpose. The problems you had in this instance are just one of the many that happen if you use Singletons, and it's unfortunate that the first official Framework, Cairngorm, encouraged their widespread use. Check out http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/ .