C# and other OOP languages

[vvanders]

Nope use it on a daily basis and it just doesn't play nice, at least on win32. Unfortunately it's required for some of the platforms we work on.

It just seems like a poorly put together IDE. You can't reference relative files outside of the project without going through a multi-step process(1. Add file as absolute 2. Re-edit path 3. sub in ${project_loc}). Their find is sub-par(why do I have to expand a billion tree-nodes to get to the final source location if I have deep namespaces like you get in Java). Ctrl-Tab equivalent goes through order tabs are opened and not order of last edited which makes quickly switching between source files slow. Can't start a build if you haven't "edited" a file in eclipse so any edits outside of the editor require touching something in the editor before it will start a build, etc.

I'm no stranger to high learning curve tools, if I'm on a non-win32 platform though I'll happily take VIM over eclipse.

[nctnico]

You shouldn't add external files but import them. That way you can choose whether Eclipse links to them based on an absolute path or relative to the project. Note that Eclipse won't allow to use versioning on imported/external files.
Regarding editing files outside Eclipse: enable the option 'Refresh using native hooks or polling' in the workspace settings. See:
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-9.htm

[zapta]

I really like python as an OOP. It's easy to learn and harder to make errors than in other languages.

... except when you copy/paste, get the indentation wrong, and it still compiles perfectly.

Python almost always complies perfectly and that's the problem.

[Stonent]

Whoa, this thread has gotten big...

Quick question:

In C# can you declare a const in your class and have all methods within that class use it without having to pass it into the class or do you just need to declare that const in main and pass it through to the method like MethodName(var1, var2, CONST1, CONST2, CONST3);

Having it at the class level would make it nice to easily update, right now the constant is inside one of my methods, but I realized another method needed that info as well so I was going to move it outside the method.  If it can be moved up to the class area and be usable without passing it into the method it would save me rewriting some code, but if it can't be done, or there's implications with doing this, I may just have to do it the long way.

[HackedFridgeMagnet]

http://stackoverflow.com/questions/6373072/defining-local-variable-const-vs-class-const
that should answer some of your question. Class constants are fine.

For 'global c style' constants I make up a public class with public constants so they are all in one place. then call something like Constants.SpeedOfLight or Constants.MaxThreads

BTW been using eclipse for years, for java, c, c++. I'll agree its not as slick as VS but it doesn't give me problems.

You shouldn't add external files but import them. That way you can choose whether Eclipse links to them based on an absolute path or relative to the project. Note that Eclipse won't allow to use versioning on imported/external files.
Regarding editing files outside Eclipse: enable the option 'Refresh using native hooks or polling' in the workspace settings. See:
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-9.htm

Useful I didn't know that.

[Marco]

... except when you copy/paste, get the indentation wrong, and it still compiles perfectly.

Python almost always complies perfectly and that's the problem.

C style commenting has the same problems (and solutions) as Python's indentation ...

Python also got a bit better than it was in the past, they stopped allowing you to mix tabs and spaces in indentation.

[VK3DRB]

I don't share your vision on Eclipse. Maybe you looked at a very early version 10 years ago but the current version detects file changes just fine. It does take some getting used to Eclipse because it has been setup for dealing with huge projects consisting of many sub-projects. It is therefore more complicated than Visual Studio. But once you get the hang of it, it works really well. It makes big spaghetti projects like the Linux kernel or a huge VHDL project managable.

I'll second that, and I have never seen the problems mentioned by vvanders.

I cannot comment on VS, since I've only used that for one tiny program.

Eclipse has annoying bugs. I am currently doing the soul-destroying job of refactoring about 50,000 lines of frogshit written by an succession of so-called electronics engineers who had no idea about embedded C programming.

On several occasions Eclipse chucked a wobbly and I lost work. Also sometimes for no apparent reason not all of the function calls, variables or constants get updated. The WinAvr compiler detects those. Maybe this mess of code is so convoluted and messed up, Eclipse is saying "You are abusing me. I'm out of here!" But I cannot complain about Eclipse - it is free and overall it is an invaluable tool for refactoring work created by dropkicks. It is a bit too Java-centric though; most most the nice add-ons are for Java applications.

I use Atmel Studio and Notepad++ as adjunct tools to help with the refactoring. With all the tools, it is a doable job. It has taken me a month already and I am about 1/4 of the way through.

[tggzzz]

... except when you copy/paste, get the indentation wrong, and it still compiles perfectly.

Python almost always complies perfectly and that's the problem.

C style commenting has the same problems (and solutions) as Python's indentation ...

Python also got a bit better than it was in the past, they stopped allowing you to mix tabs and spaces in indentation.

1) just so

2) oh good grief! Not a case of reinventing the wheel, more a case of fitting an elliptical wheel! Some of us remember the original makefile format where spaces and tabs had different meanings; everybody using makefiles wasted some of their life over that misfeature.

[miguelvp]

Like everything else, only careless ones lost time. Cobol and Fortran were column based, and there was no confusion.
Granted things have changed since then, but you gotta learn the rules to play the game

[tggzzz]

Like everything else, only careless ones lost time. Cobol and Fortran were column based, and there was no confusion.

Because you could see the columns.
You can't look at

Code: [Select]

    hello
    hello
and tell whether or not there is difference between the two lines. You have to open an editor, move to the correct position, then move again and see how far the cursor moves.

Try that with line-oriented editors, which were the norm when the original format was designed (even with screen editors, it is bad enough!)

[miguelvp]

You have to use the right tools.

[zapta]

... except when you copy/paste, get the indentation wrong, and it still compiles perfectly.

Python almost always complies perfectly and that's the problem.

C style commenting has the same problems (and solutions) as Python's indentation ...

Python also got a bit better than it was in the past, they stopped allowing you to mix tabs and spaces in indentation.

My problem is more with the lack of static typing (that is, a compile time constraint on the types of arguments and variables). It is less readable IMO and defers much of the type checking to runtime (assuming the the code is covered). 

Last year I implemented an internal systems and did it in Python to speed up the development.  After a week or so I realized that  as the code becoming more complex the development slows and the code becomes less maintainable, so I rewrote it in Java and continued the development in Java.

Static typing is a very strong language feature.

[tggzzz]

My problem is more with the lack of static typing (that is, a compile time constraint on the types of arguments and variables). It is less readable IMO and defers much of the type checking to runtime (assuming the the code is covered). 

Last year I implemented an internal systems and did it in Python to speed up the development.  After a week or so I realized that  as the code becoming more complex the development slows and the code becomes less maintainable, so I rewrote it in Java and continued the development in Java.

Static typing is a very strong language feature.

I wholeheartedly agree.

Static compile-time typing is an excellent form of self-documentation, easy way for the compiler to eliminate silly errors, and prerequisite for allowing an environment to guide you through other people's codebases including libraries.

Strong run-time typing enables decent debugging technology, allows elimination of dangling pointers (though not "data cancer"), and enables all sorts of advanced programming techniques (some of which can be abused).

[nctnico]

I don't share your vision on Eclipse. Maybe you looked at a very early version 10 years ago but the current version detects file changes just fine. It does take some getting used to Eclipse because it has been setup for dealing with huge projects consisting of many sub-projects. It is therefore more complicated than Visual Studio. But once you get the hang of it, it works really well. It makes big spaghetti projects like the Linux kernel or a huge VHDL project managable.

I'll second that, and I have never seen the problems mentioned by vvanders.

I cannot comment on VS, since I've only used that for one tiny program.

Eclipse has annoying bugs. I am currently doing the soul-destroying job of refactoring about 50,000 lines of frogshit written by an succession of so-called electronics engineers who had no idea about embedded C programming.

On several occasions Eclipse chucked a wobbly and I lost work. Also sometimes for no apparent reason not all of the function calls, variables or constants get updated.

For large projects you may need to tweak the memory limits for the indexer otherwise it can't keep track of all the variables.

[SirNick]

Ah yes.  Taking memory management out of the programming language and putting it into the IDE where it belongs. 

[miguelvp]

How will the IDE know how the hardware is put together for the target device or how is it being used?
Or the language for that matter, it should be up to the programmer.

Edit: by programmer I mean the coder.

[SirNick]

Just a tongue-in-cheek comment...

I was referring to the popular opinion that modern HL languages are better than C/C++ because you're not forced to manage memory -- but, with a popular IDE, you have to (or might have to) tweak the memory management to support context sensitive completion for large code bases.

IMHO, the IDE can and should use as much memory as it requires.  I don't care.  Just keep allocating more as necessary until I run out of RAM.  If that happens, I'll add more or prune my project.  But I like my languages to be lean and mean. 

[tggzzz]

But I like my languages to be lean and mean. 

I don't think anyone has claimed that the C++ language is lean and mean.

Personally I like my languages and run-time environments to be, to paraphrase Einstein, as lean and mean as possible, but no leaner and no meaner.

That does, of course, presume there is a stated objective/purpose against which leanness/meanness can me measures - and implies different objectives/purposes are to be expected.

[nctnico]

IMHO, the IDE can and should use as much memory as it requires.  I don't care.  Just keep allocating more as necessary until I run out of RAM.  If that happens, I'll add more or prune my project.  But I like my languages to be lean and mean. 

The creators of Eclipse and Java have put some conservative memory restrictions in place. If you Google for 'Eclipse more memory' you'll find several ways to allow Eclipse to use more memory and deal with exceptionally large projects.

[vvanders]

Which has never been an issue with any other IDE that I've used on commercial projects(with codebases nearing the million loc)  .

[nctnico]

That may be but those probably wheren't written in Java running in a virtual machine (JVM)

[VK3DRB]

I don't share your vision on Eclipse. Maybe you looked at a very early version 10 years ago but the current version detects file changes just fine. It does take some getting used to Eclipse because it has been setup for dealing with huge projects consisting of many sub-projects. It is therefore more complicated than Visual Studio. But once you get the hang of it, it works really well. It makes big spaghetti projects like the Linux kernel or a huge VHDL project managable.

I'll second that, and I have never seen the problems mentioned by vvanders.

I cannot comment on VS, since I've only used that for one tiny program.

Eclipse has annoying bugs. I am currently doing the soul-destroying job of refactoring about 50,000 lines of frogshit written by an succession of so-called electronics engineers who had no idea about embedded C programming.

On several occasions Eclipse chucked a wobbly and I lost work. Also sometimes for no apparent reason not all of the function calls, variables or constants get updated.

For large projects you may need to tweak the memory limits for the indexer otherwise it can't keep track of all the variables.

Thanks for the tip. I might try that tomorrow at work. It might save time in refactoring.

Speaking of which, I have found that almost EVERY line of the 50,000 lines needed refactoring. Entire functions have been rewritten to make them run efficiently. The goodness in all of this is maybe a sense of satisfaction at the end I have turned crap into clay, if I don't have a mental breakdown first. Also, the code will be maintainable from then on.

[nctnico]

Working on crappy code can be a bitch. I once worked on software for which the author didn't know he could use multiple source files in a C project and he didn't like to put stuff in functions either. The end result was a single file with a few functions, even switch/case statements spanning thousands of lines. I printed everything (still on a matrix printer) and annotated everything by hand to identify the stuff I had to change. At some places there where chunks of code which I could replace with 3 lines of code which did exactly the same. Oh horror 

[VK3DRB]

Working on crappy code can be a bitch. I once worked on software for which the author didn't know he could use multiple source files in a C project and he didn't like to put stuff in functions either. The end result was a single file with a few functions, even switch/case statements spanning thousands of lines. I printed everything (still on a matrix printer) and annotated everything by hand to identify the stuff I had to change. At some places there where chunks of code which I could replace with 3 lines of code which did exactly the same. Oh horror 

Thank is pretty bad. But what I am dealing with is much much worse. Seriously so.

Examples:
(a) tHisisa_FuntTHAT_IMADE_pm(unsigned char a, unsigned char p).
(b) A function called do_nothing(), which contains a timer loop and a watchdog timer reset routine.
(c) rrunDAIG(), where DAIG is meant to be Diagnostics.
(d) Putting a watchdog reset in a 1ms timer interrupt. Tossers!
(e) About 200 files all up - 100% of which had names which meant nothing or were ambiguous.
(f) Functions put into random files.
(g) Extreme abbreviations like get_prdc_get_tm_sm() where the acronyms have no logical meaning.
(h) 5000 lines reduced to about 700 lines yesterday. Cut 'n paste kiddies.
(i) Up to 6 levels of Gets and Sets all over the place. Bloody Windoze OOP programmers.
(j) #defines without any case consistency. eg a_COnstant, A_constant, acon, Acon, whatever they wanted. You cannot easily depict a constant from a variable.

No joke, this is a nightmare. 50,000 lines worth. Every line of code has had to be refactored. There is more spaghetti in that code than in a bolognese for a large Italian wedding.

The good news is the more I do the less I have to do. The other good news is if there are people let loose out of universities writing this sort of frogshit, there must be a demand for people to refactor code. I feel like charging $200 per hour to do this.... $100 for my pocket and $100 for psychological rehab.

The other good news is the weekends.

[tggzzz]

There's another way in which you can come across incomprehensible source code in any language, although C is the most common. Starting point: regarding C as a portable assembler. The point is to realise that the C (or whatever) code isn't the actual real source code, but C is being used as an intermediate portable code. Instead the "real source" code is written in another language, and the C is autogenerated from that "real source" code.

I first saw that in the 80s, where Kyoto Common Lisp was compiled down to C.

Nowadays the starting point is typically

• scrotty little Domain Specific Languages written by computer software graduates who don't feel fulfilled unless they are implementing a compiler, or
• Finite State Machines, sometimes generic, sometimes highly specialised in which case they are an example of a DSL

A neat "job preservation trick" is to supply a project's deliverables in the form of the incomprehensible C "source code", so that any changes imply re-hiring the originating company or contractor.

Apart from that, I suspect the worst C code I ever saw was actually assembler converted back to C, for reasons unknown.