|
|
Thanks
I need to implement the COM Server as exe and it should support automation interfaces
|
|
|
|
|
Hello
what does this error mean?
"500-inernal server error .
There is a problem with the resource you are looking for, and it cannot be displayed."
This project has been written with visual studio .net 2010 and the database is ms sql server 2008.
Every few times I am faced with this error.
Can anyone help me to solve this error ?
Thanks
Davood
D.riazi
|
|
|
|
|
This is too little information to provide any sort of real analysis.
Are you accessing a file anywhere? Maybe your path to that file is not correct
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
Read the forum guidelines. You have already posted this in another forum.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
you should check given link to find out the error
Error Message[^]
Hope it will work 
|
|
|
|
|
I often work with smelly code. One of the things that really stands out to me in the smelly code is long functions/methods. A method will often span many screens and I find it very difficult to follow.
My code used to be like this... when I was at school. I used to think I was a very good coder because I could write long and complex methods. These days I haven't really got the patience for it. Why should I have to work with this code?
Coding for me these days is more like a piece of art or a story. My methods tend to be very small, sometimes one or two lines. I do wonder whether I have lost some of my ability to work with long methods. Is working with bad code a skill that needs practicing?
How would other people see my code? My coding style is very unique compared to what other people on my team do. Although it looks good to me will they find it difficult to work with? Will it be hard to understand if people have never seen this style before?
When I'm changing code I also like to improve (IMO) it, I will use the 'extract method' feature in places to make it more readable. What will people think of this though? They may think I am spoiling 'thier' code.
|
|
|
|
|
I can't smell a question here.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I'm interested in peoples thoughts. Other people must be in similar situations too.
|
|
|
|
|
Your organisation needs to invest in copies of Ndepend[^]. Introduce your team mates to the joys of reducing cyclomatic complexity.
|
|
|
|
|
That looks good. I've used the code metrics in Visual Studio which has the cyclometric complexity, but it looks like this does a bit more.
|
|
|
|
|
I think this post would be much better in soapbox forum.
|
|
|
|
|
Member 4487083 wrote: I used to think I was a very good coder because I could write long and complex methods.
If you're writing long complex methods, you're not breaking down your problems correctly. If I was supporting your code, I'd have to hunt you down and remove your DNA from the face of the earth.
Member 4487083 wrote: How would other people see my code?
The above pretty much sums it up...
|
|
|
|
|
Methods that are only one or two lines long probably means your call stacks are absolutely huge and debugging probably feels like a huge expedition. Spaghetti code gets its name not only because of the length of the noodle, but the number of noodles in the bowl.
What are your criteria for breaking functionality out into its own method? Length of method is rarely the best way to decide. Do you use UML or anything to document your code? Are these methods usually private or public? Do your classes and methods make sense when you describe the functionality in a sentence? For instance, a Dog object has a Tail object property which has a Wag() method. So a dog has a tail than can wag.
|
|
|
|
|
My call stacks aren't huge because the smallest methods are usually very simple and don't call much else. It's probably hard to judge it without seeing it. What really stands out to me though is when methods are 500 lines long, or in some cases more than 1000 lines long.
I don't use UML, to be honest, I've never considered using it. I always saw it as a way to communicate ideas to others and not a form of documentation. You could argue that my code is (often) documented by developer (unit) tests though.
I usually break up the code based on whether it makes sense, and reads like a sentence. It certainly isn't broken up based purely on the number of lines.
I try to follow most of the guidelines in 'Clean Code' by Bob Martin. This is a really good book IMO.
|
|
|
|
|
So your call stacks aren't long and your methods are 1 or 2 lines. Yet your code does the same thing as something with methods 500 to 1000 lines long? Either you have 250+ methods, or you aren't comparing code with equivalent complexity.
|
|
|
|
|
T M Gray wrote: So your call stacks aren't long and your methods are 1 or 2 lines. Yet your code does the same thing as something with methods 500 to 1000 lines long? Either you have 250+ methods, or you aren't comparing code with equivalent complexity.
Well, there's a balance between the two really. A single 1000 line method probably isn't ideal, and 1000 single line methods probably wouldn't be ideal either. Is there a problem with writing 250+ methods though? If you have a complex problem then you may create a number of classes and methods for it. Putting 250+ methods in a single class probably isn't great, but if you have that much code then it can probably be split up into multiple classes.
My call stack would be longer, but I wouldn't normally consider them to be too long. I generally don't see this to be an issue. It can also be useful when an exception is thrown and logged (or unhanlded). Exceptions give you the stack trace, and if an exception is thrown in a 500+ line method then it's likely to be more difficult pin point the problem than if it was a 10 line method.
You are right about the complexity in some ways. However, almost all of the long methods I see can easily be broken down into smaller parts. Even breaking them into methods with 100 lines of code would make the code much more readable.
Although I do write single line methods, a lot of code is more than a couple of lines long, but never 500+ lines.
|
|
|
|
|
If you have 250+ methods then I'd say that you immediately violated Single Responsibility.
|
|
|
|
|
Pete O'Hanlon wrote: If you have 250+ methods then I'd say that you immediately violated Single Responsibility
Agreed. SRP would be violated just as much if the same code was within a single method though.
|
|
|
|
|
Indeed - the point I was trying to make was that the code should be better in other classes.
|
|
|
|
|
Member 4487083 wrote: one or two lines
That's probably too short. How often are they called? From how many places?
When I have a really short method that gets called frequently I reach for the C pre-processor and write a macro. 
|
|
|
|
|
PIEBALDconsult wrote: When I have a really short method that gets called frequently I reach for the C pre-processor and write a macro.
In C# it will often get inlined by the JIT anyway so there shouldn't be any performance issues.
|
|
|
|
|
Member 4487083 wrote: will often get inlined
But it seems unpredictable.
|
|
|
|
|
Does the performance difference matter? On the occassions where it doesn't get inlined I suspect that the performance difference won't matter in at least 95% of situations. There are other performance disadvantages of large methods though.
|
|
|
|
|
Like what? (Just askin'.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
