What Programming Tools do you use?
 

What programing tools do you use. What software packages if any do you use. Do you vi, pico, emacs, or is there some other tool which you use. I am looking to get into Linux programming but want to know what tools you programmers of LQ use.

Found a number of C++ tutorials. It has been so long since I even done anything in c. I remember doing c in high school using visual studios 6. That was my freshman year too.

As far as Linux programming goes, any other languages worth knowing or learning bides c++? I know a number of web programming languages such as php, html. So I don't think it will be to difficult to learn, except I just have to learn a different language and structure.

Any suggested reading on keeping code clean and organized, or any standards to follow. i.e. Follow the structure below.


Begin Declaration
Declaration Variable
Variable Value 1
Variable Value 2
End Declaration Variable
End Declaration

i use kwrite, kedit, gwrite or gedit as they colorize the syntax which can help to a small degree with debugging

I answered to a previous thread there:
http://www.linuxquestions.org/questi...semble-670270/
I think that it can interest you.

I'm using gvim (it does syntax coloring, and with a macro, does the completion too), write the makefiles by hand if tyhe project isn't too big, else i'm using autotools/autoconf. Add to these csope and ctags to open a file a the right place, and doxygen for the code documentation.

I use KWrite. The main reason I use KDE instead of Gnome is that KWrite seems to have a wide range of decent syntax highlighting for lots of languages, better than Gedit.

That's kind of like asking "how high is up?". Alot of this depends on personal preferences, and what you're trying to accomplish. VI is great if you're needing 'quick and dirty' from a terminal window, but Kdevelop or Anjuta are my preferred editors...context-sensitive editors make things much easier.

Under Linux, you have access to Ruby, Perl, PHP, Python, C/C++, BASH script, and many other languages. They all have their good and bad points, and can all do alot of the same things, but as for which to use, it depends on what you're trying to do. I wouldn't write a database application in PHP, but for web interfacing it's great. Perl can chew up data easily, but writing a GUI based app it's a little clunky.

As far as keeping it clean and organized, that depends on you. Some things I do:

- try to make your variables something that you can recognize, that have something to do with what the variable IS. Naming a variable that contains the first-name field "$f1902" won't help you later. "$Fname" is a bit better.
- Comment like there's no tomorrow. They're free to use, and if you comment the crap out of things, you can follow it easier. Say where you get the data from, what that particular block is doing with it, and where it sends the data from there. Explain logic behind what you're doing; sometimes, I even put comments on each line, if things are a bit hairy. Yes, it's a pain, but in a year or so when you go to look at your own code, you won't remember why you did what you did. The comments will greatly help.
- Space things out, indent well and consistently. This will make finding the end of something easier, IMHO.
- Try to use the best-practices of whatever language you're using. In Perl, use strict. Try to make things behave the way the designers intended.

I use scons, make, gdb, vim, jedit, kate (or any other available text editor). I don't use emacs or any IDE.

python. Or perl. Or any other interpreted language. Helps for writing quick utility programs. I recommend python.

html isn't programming language.

Here you go:

I use following set of rules (C++ rules, partially taken from Qt4 source):
1) class name or any typename always starts with uppercase letter.
2) function name always starts with lowercase letter
3) long function or class names are written as: "veryLongFunctionName" and "VeryLongClassName".
4) underscores should be avoided. no "very_long_function_name" stuff.
5) member names and class variables do not use special prefixes (things like m_classVariable are not allowed)
6) type of variable is not indicated in it's name (lpszStr is not allowed)
7) All constants are stored as unnamed enums, when possible.
That is unless constant is required to be variable.
8) constant names start with lowercase letter.
9) All enums or constants should be put into namespace or a class, unless they aren't declared into *.h (i.e. internal, used only in one *.cpp file). This keeps global namespace free of junk.
10) Global variables or functions should not be used in large projects. Large means larger than 10kbytes source code. Any global function or variable should be put into namespace or class. This helps to avoid name clashes, and keeps global namespace clean.
11) NULL is not used, because it doesn't have special meaning in c++. 0 (zero) is used instead of null.
12) Pointers as parameters should be used only if argument is a pointer to first element of array, or function should be able to take 0 as argument. In all other cases references should be used. This makes code self-documented.
14) Or pointers or references in function arguments should be declared as "const" unless function writes to that pointer.
15) Short function/variables should be avoided. All function names, class names, and variable names should be as descriptive as possible. From short names, only "i" is allowed, because it stands for "iterator"
16) Most functional classes should be placed into separate *.h and *.cpp file, which should have same name as class. This helps to keep code organized. I.e. class MyClass should be stored in separate files "MyClass.h" and "MyClass.cpp" even if each is 20 lines big. The exception of the rule is allowed only if class is declared for internal use (subclassing, etc, helper classes for STL, etc) and isn't supposed to be used (or even visible) in other places. In this case class might be declared inside *.cpp near the place of usage.
17) All member functions should have "const" modifier unless they change class fields or internal data. This keeps code self-explanatory. Example:
18) Opening curly bracket is placed at the end of line.
19) Closing curly bracket is placed on separate line
20) There is no space between ")" and "{"
21) There is always empty line at the end of each file (requirement of unix compilers).
22) All classes and functions should be as short as possible, when it is possible. dozen lines or two, not more.
23) Function or member function should never be completely written in header, unless it is inline or template. Helps to avoid many errors.
24) Only template classes can be completely written in header files. For normal classes all function should be "mentioned" in header, but body should be kept in the corresponding *.cpp file.
25) When class uses multiple inheritance, dynamic_cast or static_cast should be used to cast class pointer into derived/base type.
26) In "if-else" block curly brackets are not used if there is only one line after if or else.
The exception is when there is nested "if" within if-else.

This should be every rule I use, however there is a chance that I forgot to mention something.

I've been using scite for programming AVR microcontrollers in C it works good with gtk and does syntax stuff. I couldn't for the life of me get eclipse to work right. in a pinch I still use nano.

Most excellent post ErV. I will definitely follow those pointers in the future. First time i have ever bookmarked one of my own threads. :)

Thanks.
However I recommend you to check some large, respected C++ projects, take a look how they write code, maybe you'll find your own style or your own set of rules which will work for your better. The "rules" I posted were based mostly on Qt 4 code (take a look at it. They had some not-so-good places somewhere, but I liked the overall style), and I started using this scheme after a year of attempts to use "Hungarian notation"(m_lpszStr stuff. Cool at first, but quickly becomes confusing. Mostly used by Microsoft) or long underscored names (GNU C projects seems to be using this scheme). I began using this style 1.5..2.5 years ago, and so far it works well for me (it's not perfect, but works well in most cases).

Editor vi or vim (does colour syntax etc). If you ever work commercially on Unix or Linux you can guarantee vi will be there and prob vim (esp on Linux). Anything else is luck.
Worth knowing the basics at least.

I'd also learn Perl. Its got a lot in common with C, but easier to prog (takes care of details like var/buffer sizes for you). Always use strict and warnings.

Do indent your code, declare & comment your vars. Comment your code, at least at block level.
In disagreement with rule 26 above, always use parentheses around an if(){}, even if its only one line of content. You never know when that will change, esp if you try to debug that line.
Personally I do prefer underscores rather than words rammed together. Easier to read.
Style is a very personal thing, but consistency is what you need.

Do learn the basics of binary and hex (and octal). Comes in handy all over the place.

I use "IDLE", for my python. It has a shell where you can run commands to test them, and a separate text editing window that will pop up little hints as to what can go in certain places. For example if I start typing:
And I stay there for a bit, a gray helper window will come up telling me what I can put there. It also has a "check module" option where it will check the syntax of your file before you actually try to run it.

Why ?

I use GNU/Emacs as my ide/text editor, mostly because it can handle just about any language and has lots of plugins written for it

Noone's using versioning systems? ;)

After my favorite editor and my favorite programming language comes something to bundle the stuff (configure scripts, makefiles or Perl's module mechanism or whatever is appropriate for the project at hand) and _of course_ some kind of versioning on some remote machine for backup.

I prefer darcs.

nothing beats git for versioning