As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Foundations of F# and Expert F# are probably the two most prevalent books used to learn f#.
Both were written at the time of the 1.9.2/1.9.3 releases.
The website for the Expert book has some errata and details some of the changes in the 2008 CTP release which were relatively minor.
However the CTP release for the 2010 beta (and the corresponding 2008 compatible release) 1.9.6.16 changes much more.
Since the MSDN documentation is largely non existent, especially in terms of changes and data is scattered around blogs I am finding it harder and harder to rely on the current books (especially the expert one) since the f# landscape has shifted too much underneath it.
This question seeks to provide a (hopefully) comprehensive list of those areas which have changed and short details/links to further reading on how to deal with this.
As the basis for this I have added some issue which impacted myself.
The previously linked blog post lists many of the changes in terse form and is a good place to start but it doesn't cover everything by any means.
Attempting to keep to a specific aspect per answer would be sensible since this will make reading it easier.
In specific question form:
What changes have occurred to f# from 1.9.6.3 to 1.9.6.16 that render previous examples (especially dead tree documentation not amenable to easy correction) incorrect or deprecated and what remedial actions are possible.
The signature of Array.sort changed; it used to be in-place, whereas now it returns a fresh array and Array.sortInPlace sorts in place. (That's been a minor problem-point for customers; most other library-renames issues deprecation warnings that steer you in the right new direction, but in this case the function still works, but has a new signature, which can make this difficult to diagnose at-a-glance.)
http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/manual/FSharp.Core/Microsoft.FSharp.Collections.Array.html
A number of books were written before FSharp.PowerPack.dll was split out of FSharp.Core.dll, so for many examples you need to ensure you've added a reference to the powerpack to gain access to certain library functions.
See also http://blogs.msdn.com/dsyme/archive/2008/08/29/detailed-release-notes-for-the-f-september-2008-ctp-release.aspx
Events
Expert F# Chapter 8 section: Events and Wiring
IEvent is entirely deprecated. Instead the various functions are defined on Event instead.
There is no longer any need to use create_HandlerEvent to make a completely compatible .Net event (one consumable from, say c# easily) instead you use the CLIEvent attribute.
If you make your event via DelegateEvent<T> then the resulting event is usable without requiring any reference to the FSharp.Core dll.
If you use Event<T> then you must include a reference to the FSharp core to be able to use it.
Naming convention changes
removal of most '_' within function names
removal of deprecated functions
Specific examples and their resolutions
List
reduce_left to reduce
Seq
sort_by to sortBy
group_by to groupBy
init_finite to init
Several functions including cons and generate_using removed
Array
scan1_left to scanReduce
reduce_left to reduce
Multiple types have moved from being part of the dedicated F# runtime (child namespace of Microsoft.FSharp, in assembly FSharp.Core):
bigint now an alias for System.Numerics.BigInteger.
Tuple is now System.Tuple
#light
#light is the default, as a result some examples online will not compile.
This has a relatively minor impact since most examples used #light anyway.
Syntax changes
with member ... and support removed. Use explicit member this.Foo for each
1.9.4 changes
the change to Symmetric Operator Overloading.
subtle changes to the handling of nulls with boxing and option types
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
DOM, ThreeJS and now canvas have all had libraries written to provide method chaining (perhaps most familiar from jQuery). Chaining has also been used in core C libraries.
These fluent interfaces avoid unnecessary repetition of the object of interest. Compare:
var cx = cq(640, 480);
cx.drawImage(image, 0, 0);
cx.fillStyle("#ff0000");
cx.fillRect(64, 64, 32, 32);
cx.blur();
cx.appendTo("body");
to:
cq(640, 480)
.drawImage(image, 0, 0)
.fillStyle("#ff0000")
.fillRect(64, 64, 32, 32)
.blur()
.appendTo("body");
It could be argued that the former "traditional" style is over-verbose, and violates DRY.
To avoid repetition of the cx variable, some languages allows us to express a set of calls using a with statement:
with ( cq(640, 480) ) {
drawImage(image, 0, 0);
fillStyle("#ff0000");
fillRect(64, 64, 32, 32);
blur();
appendTo("body");
}
Whilst JavaScript's with statement is dangerous in the presence of typos, Scala's more restrictive with statement is safe to use, and Haxe also offers import of functions to the local scope through its using keyword. Unfortunately Java and C offer no such shortcut, forcing us to choose between traditional code or chaining.
Should language authors consider a safe with-like statement as an alternative to method chaining, or are there good reasons to avoid it? If such a feature is desirable, what form should it take?
One concern I have with method chaining is that the ambiguity about the subject of the later calls in the chain may prevent optimizations previously available when compiling code where repeated use of cx was explicit. For example, if the calls to cx's methods do not overlap, they could be parallelized, but it may be harder for the compiler to be sure of this in the chained example.
Another disadvantage, as rambo points out below, is that methods designed for chaining are unable to return any other value, which seems rather wasteful.
It's called Method Chaining. It frequently appears in the discussion of a Fluent Interface.
Perhaps the biggest drawback is that you cannot return a value, because you must return the implied object to allow chaining. Not all methods make sense without returning a value, and then you end up with an interface that has some chainable methods, and some not.
I don't think it indicates a missing language feature, because there's no serious loss of functionality without it. But language support for somethign like this might be interesting.
It's not a missing language feature, instead it is a language feature. If it was missing then it wouldn't be possible to do it in Javascript.
This is not syntax. Instead, it is a design pattern. And it's called chaining. In fact, there are libraries that implements chaining alone. DED|Chain for example is a library that implementes chaining for YUI2 which was not written with chaining in mind.
A specialized syntax like with (which is indeed implemented in js like you mentioned) is problematic regardless what you call it (you suggested using the name "on" but it will have all the problems that "with" has).
The problem is, inside a code block, it can be confusing to a human (the compiler is not confused) weather the method or variable refers to method of the object or if there was a typo and it accidentally refers to a global variable or a variable that is not part of the object but is in scope.
Of course, you could say that it is the job of the programmer to make sure that they don't use variable and method names that may cause confusion. In which case you can use with.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Personally I can't stand region tags, but clearly they have wide spread appeal for organizing code, so I want to test the temperature of the water for other MS developer's take on this idea.
My personal feeling is that any sort of silly trick to simplify code only acts to encourage terrible coding behavior, like lack of cohesion, unclear intention and poor or incomplete coding standards.
One programmer told me that code regions helped encourage coding standards by making it clear where another programmer should put his or her contributions.
But, to be blunt, this sounds like a load of horse manure to me. If you have a standard, it is the programmer's job to understand what that standard is... you should't need to define it in every single class file.
And, nothing is more annoying than having all of your code collapsed when you open a file. I know that cntrl + M, L will open everything up, but then you have the hideous "hash region definition" open and closing lines to read.
They're just irritating.
My most stead fast coding philosophy is that all programmer should strive to create clear, concise and cohesive code. Region tags just serve to create noise and redundant intentions.
Region tags would be moot in a well thought out and intentioned class.
The only place they seem to make sense to me, is in automatically generated code, because you should never have to read that outside of personal curiosity.
I like regions, and use them all the time. I use them to group members of the same kind inside classes.
You already have the means to collapse methods, classes and namespaces in the editor. Regions give you an option to create another level that lets you arrange the code in a way that corresponds to what you think is important.
StyleCop doesn't like regions:
SA1124: DoNotUseRegions
Cause
The C# code contains a region.
Rule Description
A violation of this rule occurs whenever a region is placed anywhere within the code. In many editors, including Visual Studio, the region will appear collapsed by default, hiding the code within the region. It is generally a bad practice to hide code, as this can lead to bad decisions as the code is maintained over time.
How to Fix Violations
To fix a violation of this rule, remove the region from the code.
There is some discussion about whether or not this is a reasonable rule.
The consensus seems to be that some people like regions and some people don't - it is up to individual teams to decide. The most important thing is to use a consistent style throughout your project.
One place where regions might be acceptable is to group all the methods that implement a particular interface. It is worth noting that Visual Studio automatically adds a region if you use the code generation feature to provide method stubs for implementing an interface.
The only place they seem to make sense to me, is in automatically generated code, because you should never have to read that outside of personal curiosity.
The partial class feature is better for separating automatically generated code from manually generated code within the same class.
When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when it creates Windows Forms, Web service wrapper code, and so on. You can create code that uses these classes without having to modify the file created by Visual Studio.
I think that #region is perfectly fine. I've never used it myself, but if you have a large or complex class, it can help with finding what you're looking for. Imagine if you're implementing ID3D10Device1- that's over a hundred methods to implement. You want to just throw them all in one place?
I do use regions to organize bigger constructs in a class, ie. a Dependency Property with callback and methods getting called by this, eg. you have a DP that takes an IEnumerable<T>, and you want to use the weak event pattern to respond to INotifyCollectionChanged. This can take some code, and as I won't be touching it after coding it, I put it in a region.
However, if you resort to regions to structure your logic, this is severe code smell and that's what the StyleCop rule in Mark's post is pointing hat.
while I am programming I use regions a lot they help me keeping my code organised and be able to focus only on parts I care. I always add comments on the regions and what are they about .But when I am done I am always removing them. Its a handy tool, that's all.
IHMO, if you have #region section in a class, it means that you have two behaviors in your class and so you should split your class in two objects.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
what tokens do you find useful in visual studio?
(visual studio 2010 → environment → task list → tokens)
currently i have only:
HACK - low
REVIEW - high
TODO - normal
WTF - high
(only these - deleted some default ones)
are you using any others?
are you covering any other important thing with comment tokens?
any best practices? thnx
Here's the ones I use:
TODO: the functionality is not yet implemented
FIXME: the code should be modified/refactored to achieve some goal (higher maintainability, better performance, and so on)
BUG: the code has a known bug
I've done a combination of most of the above tokens.
RED: code that simply does not work / compile
// Error - This code is throwing a specific reproducible error.
// Broken - This code is broken and will not run.
// WTF - WHAT THE FRIG.
ORANGE: code that works but is not right
// Hack - This code has intentionally been hacked in order to work. Should not go into production.
// FixMe - This code works but could be better. Needs better abstraction, maintainability, performance, etc.
// Bug - This code works and was expected to be right but a bug has been found. (usually flagged post production)
// Review - This code is probably right but should be reviewed for piece of mind.
// Smells - Same as FixMe
BLUE: code that works but either needs more features or more explaining
// Todo - Functionality is not yet implemented
// Note - Better explain what's going on. This is gives a higher profile to standard comments, and allows notes to be found in the to-do pane.
I like the Token REMOVE, indicating that it's only in for testing, and should not be included in the final release
Another built-in is NOTE.
Vim automatically highlights XXX, which happens to be my token of choice for the ease of typing it.
Sun's (old) Java coding conventions have this to say:
Use XXX in a comment to flag something that is bogus but works. Use FIXME to flag something that is bogus and broken.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 14 years ago.
How do you explain your team mates the importance of commenting the code they write? I know some coders who write episodic comments while others leave a lot to be expected, what do you expect when you read comments?
There are some minimums:
All functions and classes should be commented
Try/Catch and exception handling is better to be commented
Constants hard coded in the code should be definitely
dummy objects and dummy classes, as well as TO-DO parts should be commented
When you get a code from a URL, the address should be cited in the comments for further consideration and copyright infringement problems
Also commits to the version control system should be well commented
Although comments should be kept to minimum, there is no need to comment a for loop definition when it is obvious,
I usually set ground rules for my programmers, they stick to it when it is well defined
The best comments are always concise, in a few words. It should say what's not obvious in the code. I see allot of people making obvious and therefore useless comments like:
if x==0 //if x equals 0 then...
oh really?! This is only "polluting" the code, because unless you're learning how to program, its pretty useless.
Even if the code is only yours, you should write comments as if you were about to share it with another programmer that is completely unaware of it. That way you make sure that you will always understand it, and in long term if somebody comes along and picks that code up, that person will be able to understand it and extend/use it.
I see comments as a boost of reusability. And I expect, like every other programmer, to fully understand a block of code with a single, simple and concise comment.
Write comments when you're writing code that's not intuitive. There's really no reason for commenting a method that just iterates an array, but when you fix a bug or have to hack something together to get around an issue, it's good to have a comment so you can quickly understand that code 6 months later (and not accidently undo it).
What do you mean by commenting code?
The actual code, or the function headers?
If you're actually talking about the code, it's a lost cause. You need to get them to write readable code and to break it into meaningful chunks. Commenting bad code doesn't make it into good code, it just leaves an inconsistent mess.
As for header documentation, you have to get them to capture the important things (e.g., surprises, directives) and compromise about trivial things (listing all parameters, repeating what the signature does). People hate documenting functions because most of the effort is spent writing trivial text that almost insults your intelligence (e.g., on getHandleToFile(), "this gets a handle to the file"). Since there are actually a lot less important details than one would expect, they'd be pleasantly surprised and would be more likely to invest the effort in those specific situations.
I think if you are writing code that others may someday have to follow, then it is prudent to leave good comments about what things are doing. If you are just writing something for yourself, the tendency is strong to leave minimal or none at all. That being said, I have had the "not so luxury" of having to go back to code I wrote 8 years ago and didn't comment adequately, in a language I don't use anymore (class ASP) and I can tell you, I wish I had left more comments!
I try to comment most of my public methods and classes, and in those comments you can read what the method does, what the meaning of the parameters is, and, if applicable, what the output will be.
I also sometimes put comments inside my methods, but, there I do not comment what I'm doing, but why I am doing it like that.
if the language you are writing in is not human readable, i suggest very granular method and procedure level comments.
if the language you are writing is human readable (C#, VB, etc..) i suggest that you use somewhat detailed comments at the method level and minimal comments at the procedure level.
Include comments for document generation on methods and classes.
Don't comment every line.
If you are doing something expected or that is not obvious from the code, explain why in comments.
The most important thing to do in commenting is to tell the truth. The number of times I've been investigating a bug only to find a section of code that is "less than obvious" along with a comment that says it's supposed to do the opposite to what it is doing. Who wins? You decide...
On a related note, any comment that is longer than the section it is documenting is normally too long.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've worked on a couple of projects where we spent a great deal of time discussing and writing elaborate coding standards covering everything from syntax layout to actual best practices. However, I have also found that these are rarely followed to the full extent. Many developers seem to hesitate to reject a code review based on coding standard violations alone. I.e. violations are committed to the repository on a regular basis.
My questions are: Do you have coding standards? What do they cover? Are they followed by everyone? And what do you do (if anything) to make sure everybody is following the standards?
I'm aware that there is a similar question here, but my concern is not so much how you could do it, but how you are actually going about it and what are the perceived benefits?
I've worked in places with barely-followed coding practices, and others where they're close to being enforced - or at least easily checked.
A few suggestions:
The most important thing is to get buy-in to the idea that consistency trumps your personal preferred style. There should be discussion of the coding standard both before and after it's instituted, but no-one should be allowed to just opt out of it.
Code reviews should be mandatory, with the checkin comment including the username of the reviewer. If you're using a suitably powerful SCM, consider not allowing checkins which don't have a valid reviewer name.
There should be a document which everyone knows about laying out the coding standards. With enough detail, you shouldn't get too much in the way of arguments.
Where possible, automate checking of the conventions (via Lint, CheckStyle, FXCop etc) so it's easy for both the committer and the reviewer to get a quick check of things like ordering import/using directives, whitespace etc.
The benefits are:
Primarily consistency - if you make it so that anyone can feel "at home" in any part of the codebase at any time, it gives you more flexibility.
Spreading best practice - if you ban public fields, mutable structs etc then no-one can accidentally plant a time bomb in your code. (At least, not a time bomb that's covered by the standard. There's no coding standard for perfect code, of course :)
EDIT: I should point out that coding standards are probably most important when working in large companies. I believe they help even in small companies, but there's probably less need of process around the standard at that point. It helps when all the developers know each other personally and are all co-located.
Do you have coding standards?
Yes, differs from project to project.
What does it cover?
Code(class, variable, method, constant), SQL naming and formatting convention
Is it being followed by everyone?
Yes, every new entrant in project could be asked to create a demo project following organization coding convention then it gets reviewed. This exercise makes developer feel at ease before starting real job.
And what do you do (if anything) to make sure everybody is following the standard?
Use StyleCop and FxCop to ensure they are religiously followed. It would show up as warning/error if code fails to comply with organization coding convention.
Visual Studio Team system has nice code anlysis and check-In policies which would prevent developers checking in code that does not comply
Hope, it helps
Thanks,
Maulik Modi
We take use of the Eclipse's save actions and formatters. We do have a suggested standard, but nobody is actually enforcing it, so there are some variations on what is actually formatted, and how.
This is something of a nuisance (for me), as various whitespace variations are committed as updates to the SVN repository...
StyleCop does a good job of enforcing coding layout practices and you can write custom rules for it if something isn't covered in the base rules that is important to you.
I think coding standards are very important. There is nothing more frustrating than trying to find the differences between two revisions of a file only to find that the whole file has been changed by someone who reformatted it all. And I know someone is going to say that that sort of practice should be stamped out, but most IDEs have a 'reformat file' feature (Ctrl-K Ctrl-D in Visual Studio, for example), which makes keeping your code layed out nicely much easier.
I've seen projects fail through lack of coding standards - the curly-brace wars at my last company were contributary to a breakdown in the team.
I've found the best coding standards are not the standards made up by someone in the team. I implemented the standards created by iDesign (click here) in our team, which gets you away from any kind of resentment you might get if you try to implement your own 'standard'.
A quick mention of Code Style Enforcer (click here) which is pretty good for highlighting non-compliance in Visual Studio.
I have a combination of personal and company coding standards that are still evolving to some extent. They cover code structure, testing, and various documents describing various bits of functionality.
As it evolves, it is being adopted and interpreted by the rest of my team. Part of what will happen ultimately is that if there is concensus on some parts then those will hold up while other parts may just remain code that isn't necessarily going to be up to snuff.
I think there may be some respect or professional admiration that act as a way of getting people to follow the coding standards where some parts of it become clear after it is applied, e.g. refactoring a function to be more readable or adding tests to some form, with various "light bulb moments" to borrow a phrase from Oprah.
Another part of the benefit is to see how well do others work, what kinds of tips and techniques do they have and how can one improve over time to be a better developer.
I think the best way to look at coding standards is in terms of what you hope to achieve by applying, and the damage that they can cause if mis-applied. For example, I see the following as quite good;
Document and provide unit tests that illustrate all typical scenarios for usage of a given interface to a given routine or module.
Where possible use the following container classes libraries, etc...
Use asserts to validate incoming parameters and results returned (C & C++)
Minimise scope of all variables
Access object members through methods
Use new and delete over malloc and free
Use the prescribed naming conventions
I don't think that enforcing style beyond this is a great idea, as different programmers are efficient using differing styles. Forcing programmers to change style can be counter productive and lead to lost time and reduced quality. Standards should be kept short and easy to understand.
Oh yes, I'm the coding standard police :) I just wrote a simple script to periodically check and fix the code (my coding standard is simple enough to implement that.) I hope people will get the message after seeing all these "coding convention cleanups" messages :)
We have a kind of 'loose' standard. Maybe because of our inability to have agreement upon some of those 'how many spaces to put there and there', 'where to put my open brace, after the statement or on the next line'.
However, as we have main developers for each of the dedicated modules or components, and some additional developers that may work in those modules, we have the following main rule:
"Uphold the style used by the main developer"
So if he wants to do 3 space-indentation, do it yourself also.
It's not ideal as it might require retune your editor settings, but it keeps the peace :-)
Do you have coding standards?
What does it cover?
Yes, it has naming conventions, mandatory braces after if, while ... , no warning allowed, recommendations for 32/64 bits alignment, no magic number, header guards, variables initialization and formatting rules that favor consistency for legacy code.
Is it being followed by everyone?
And what do you do (if anything) to make sure everybody is following the standard?
Mostly, getting the team agreement and a somewhat lightweight coding standard (less than 20 rules) helped us here.
How it is being enforced ?
Softly, we do not have coding standard cop.
Application of the standard is checked at review time
We have template files that provide the standard boilerplate
I have never seen a project fail because of lack of coding standards (or adherence to them), or even have any effect on productivity. If you are spending any time on enforcing them then you are wasting money. There are so many important things to worry about instead (like code quality).
Create a set of suggested standards for those who prefer to have something to follow, but leave it at that.
JTest by ParaSoft is decent for Java.
Our coding standards are listed in our Programmer's Manual so everyone can easily refer to them. They are effective simply because we have buy in from all team members, because people are not afraid to raise standards and style issues during code reviews, and because they allow a certain level of flexibility. If one programmer creates a new file, and she prefers to place the bracket on the same line as an if statement, that sets the standard for that file. Anyone modifying that file in the future must use the same style to keep things consistent.
I'll admit, when I first read the coding standards, I didn't agree with some of them. For instance, we use a certain style for function declarations that looks like this:
static // Scope
void // Type declaration
func(
char al, //IN: Description of al
intl6u hash_table_size, //IN/OUT: Description of hash_table_size
int8u s) //OUT: Description of s
{
<local declarations>
<statements>
}
I had never seen that before, so it seemed strange and foreign to me at first. My gut reaction was, "Well, that's dumb." Now that I've been here a while, I have adjusted to the style and appreciate how I can quickly comprehend the function declaration because everyone does it this way.