Rune FS

216 reputation

bio	website	runefs.com
	location	Copenhagen, Denmark
	age	37
visits	member for	2 years, 4 months
	seen	Feb 26 at 9:18
stats	profile views	28

I'm a Solutions Architect with experience from a lot of different fields ranging from server monitoring, web sites/portal to my current project within medical devices.

In my spare time I'm working on a compiler for a new language called Marvin. It's build to have naitive support for DCI. The same ideas that went into Marvin has been put into my first ever Ruby project called Maroon, both enables injectionless DCI on each their platform.

More information on both can be found at my blog or on the DCI community site

	216 reputation	bio	website	runefs.com	visits	member for	2 years, 4 months
28 badges		location	Copenhagen, Denmark		seen	Feb 26 at 9:18

summary answers questions tags badges favorites bounties reputation activity

32 Comments

suggestions reviews revisions comments badges posts accepts all

Feb 24	comment	Self Documenting Code Vs. Commented Code @Sk-logic what a bizzare statement "At least my point is proven by X and Y and your's is simply a weird assumption on Z" firstly the assumption on developers ability to maintaining a design document was your's you Said they would only maintain it if it was in the code. Secondly I have analysed metrics for a huge set of projects (thousands of OSS projects) and found no indication what so ever that comments moser the risk of errors
Feb 24	comment	Self Documenting Code Vs. Commented Code @Sk-logic. You made my day again :) paraphrase: "Developers are more likely to maintain a piece of documentation in location A than B" in my experience that's a falsum. I don't have any file size assumption at all. The lines of text in a file can't be determines with out scanning all the files. If the files scanned are big it takes time Always! That's not an assumption on file size that part of the problem definition. Bear in mind we haven't dicussed how ReadAllLines work and that might be heavily parallelized but that doesn't matter for understanding the functionality of the code in question
Feb 24	comment	Self Documenting Code Vs. Commented Code @SK-Logic: You seem to be missing my point. Using Contract I can in a formal unambigious way code any comment of importance. Such as invariants. Why I wrote the code as I did does not belong in the code but in a design document. Thaqt said I got absolutely no clue what you're talking about here: " reason why you're relying on the file size assumption" there's no file size assumption. The size isn't used.
Feb 24	comment	responsibility for storage In the case where the design and hence inheritance is flawed maybe. if you have stuck to SRP all the way and the object can be serialized then no
Feb 24	comment	Self Documenting Code Vs. Commented Code @SK-logic But still you claim that important invariant should be commented rather than coded: "The one who wrote it must clearly explain what are the limitations he's expecting here" still comments can rot whereas the compiler complains if the code does public int LinesInFile(string fileName){ Contract.NotNullOrEmpty(fileName); Contract.Assert(File.Exists(fileName)); var fileContent = File.ReadAllLines(); return fileContent.Count(); } Any one that can't figure that code out will not be helped by any amount of comments you write
Feb 24	comment	Self Documenting Code Vs. Commented Code @SK-logic you just made my day. Why do you think people pay more attention to comments than code? I for one certainly do not. I know the code is what actually happens and know that the comments might be misleading/incorrect
Feb 24	comment	Self Documenting Code Vs. Commented Code @SK-logic var fileContent = File.ReadAllLine(fileName); That's a line of code with some very complex logic behind it but just from reading the names of the identifiers I'd say it's very easy to read the intention. I'm pretty sure it can't get more generic and I know it's not redundant
Feb 24	comment	Self Documenting Code Vs. Commented Code @SK-logic compact code != generic code. On the generic code I agree but to me that's a supporting statement to what Peter wrote not an argument against it
Feb 24	comment	Self Documenting Code Vs. Commented Code Seen from an empirical point of view comments in comparison to LOC or cyclomatic complexity makes no difference to the error proneness of the code. So what gain are you aiming at when you suggest writing comments?
Feb 24	comment	Self Documenting Code Vs. Commented Code @SK why? Compact code has been proven to be more error prone than elaborate code. Part of the reason for that being believed to be readability.
Feb 24	comment	responsibility for storage why embed the knowledge of the store into the class. It doesn't make things simpler. The code written in another class to store can be exactly the same but you do not get the added complexity of mixing things
Feb 24	comment	Empirical average values of various metrics? "but to compare a software project" compare what? for equality on the metrics or to use the metrics to give informed guesses on maintanance cost,error proneness, design work put into the project or something different. If you're not telling us what task you're trying to solve how can we help?