L
Linonut
* AqD peremptorily fired off this memo:
> Have you ever tried Code-Forge, or SlickEdit, or X-develop?
Nah, just Visual Studio and CodeWright.
> In code-forge, you can have code analysis and true c++ auto-completion
> (it even takes macros into account), and the project orgenizer can let
> you edit complex dependencies in make, though not automake'ed I think
>
> SlickEdit gives you refactorying for C++, so you can rename or move a
> method in the whole project, without worrying about other related
> code.
>
> X-develop has background checking - not only syntax, but also missing
> method/variable, duplicated code parts, etc - when you're typing. So
> before you ever make/compile you could already fix most errors.
>
> They're designed for linux/unix or cross-platoform, but less known to
> most developers, and probably never recommended by anyone who use
> linux - because they're not free.
That stuff's cool, but you pay a price for it in speed. And, if you
start to depend on it, then you are not so flexible when you go to a
different work environment. And that's ignoring the money.
I paid over $200, twice, for CodeWright. If I had known about vim,
I could have saved myself a lot of money.
Tools like cscope, etags, flawfinder, and many others will help you,
and give you much of the same functionality as the tools above,
though you have to activate them manually. I suspect Emacs has a lot of
tools that do some of the stuff you mention above. In vim, you can
issue a make while you are editing, anytime you're curious, and have vim
step through each error.
My method of building code is to comment early, and build early, and
then comment and build continuously. There's no substitute for knowing
what you are doing, being alert, and write the destruct code at the same
time as the construction code.
And keeping your design small and API concise.
Here's an object lesson from a Windows master:
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
But I'm an old-school guy. What do I know? I started out using EDLIN
and DEBUG on MASM source-code files that were up to 1 Mb in size.
On PCs that were lucky to have the full 640K of RAM. I would have
dropped dead from envy if I had known about the tools that were available
to the UNIX programmer back in 1985. (I did have a nice vi for the PC,
but the company wouldn't allow me to use it.)
--
Microsoft is not about greed. It's about innovation and fairness.
-- Bill Gates
> Have you ever tried Code-Forge, or SlickEdit, or X-develop?
Nah, just Visual Studio and CodeWright.
> In code-forge, you can have code analysis and true c++ auto-completion
> (it even takes macros into account), and the project orgenizer can let
> you edit complex dependencies in make, though not automake'ed I think
>
> SlickEdit gives you refactorying for C++, so you can rename or move a
> method in the whole project, without worrying about other related
> code.
>
> X-develop has background checking - not only syntax, but also missing
> method/variable, duplicated code parts, etc - when you're typing. So
> before you ever make/compile you could already fix most errors.
>
> They're designed for linux/unix or cross-platoform, but less known to
> most developers, and probably never recommended by anyone who use
> linux - because they're not free.
That stuff's cool, but you pay a price for it in speed. And, if you
start to depend on it, then you are not so flexible when you go to a
different work environment. And that's ignoring the money.
I paid over $200, twice, for CodeWright. If I had known about vim,
I could have saved myself a lot of money.
Tools like cscope, etags, flawfinder, and many others will help you,
and give you much of the same functionality as the tools above,
though you have to activate them manually. I suspect Emacs has a lot of
tools that do some of the stuff you mention above. In vim, you can
issue a make while you are editing, anytime you're curious, and have vim
step through each error.
My method of building code is to comment early, and build early, and
then comment and build continuously. There's no substitute for knowing
what you are doing, being alert, and write the destruct code at the same
time as the construction code.
And keeping your design small and API concise.
Here's an object lesson from a Windows master:
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
But I'm an old-school guy. What do I know? I started out using EDLIN
and DEBUG on MASM source-code files that were up to 1 Mb in size.
On PCs that were lucky to have the full 640K of RAM. I would have
dropped dead from envy if I had known about the tools that were available
to the UNIX programmer back in 1985. (I did have a nice vi for the PC,
but the company wouldn't allow me to use it.)
--
Microsoft is not about greed. It's about innovation and fairness.
-- Bill Gates