What is the basic coding style for a linux developer ?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Really basic?
Make it readable (for humans), the compiler doesn't care about style, only about the code being correct.
Indent. Start a for, indent everything withing that section, including more indents for if - else and other conditions.
If you're using vi/vim, you can set two helpful things in a file .exrc in your home directory, looks like this:
Code:
cat .exrc
set autoindent showmode showmatch
autoindent keeps track of tabs, hit a tab (for indent) and that will line everything up with additional tabs; you "go back" with ^D one indent level at a time. Pretty handy and no clicking on anything.
showmatch gives you a visual indication that you've got the correct number of parens, brackets or braces; the cursor will jump back to the match but won't budge if you're doing too many.
showmode doesn't do much of anything but, every so often, you'll see something happen about what mode you're in. Can't hurt, might help.
You really do not want to write code in a word processor, use the editor instead.
The coding style tends to be the same as they are on the job IME. Just the tools are different. Although the last time that I had a programming job, I didn't do much coding on work nights. The duties of the job left you pretty spent after a days work. But on the weekends you get to focus on your interests. Which for me was silly graphical stuff in java. Versus playing text video games with other peoples data in whatever the company chose to use. Probably platform specific like VB, and probably what it used to be a decade ago when they bought into the platform. And probably on hardware just as old because of policies and such.
About the only style difference is make it work, on the job, and make it pretty, when not getting paid (which is the stuff you'll likely show others). But in general I strove for maintainable and fewest lines of code. At least after I knew enough about a given language. Even if I knew advanced techniques I avoided them. That's the stuff that got broken when the language or platform changed. Plus dumbing it down made it easier on interns (and managers) to review and maintain your past projects.
Distribution: Linux From Scratch, Slackware64, Partedmagic
Posts: 3,137
Rep:
get the code working first then mpretty it up, you can use somthing like astyle for c code wich is quite customizable, available on sourceforge, i use it then do a few minor tweaks for hoa i like the code set out
Not a fan of make it work, then fix it methodology. It's fine in a "perfect" world, and what most employers are willing to pay you for. But in practice, the network goes down, the storage devices fill up or become unavailable. The servers you're "waiting on" don't respond. It's better to take your time, to map it out so it's a batch process that can be (re)started from any ONE step in the process. Not really multi-thread-able though. But break your process out, one to identify changes, one to do changes, one to verify changes, one to clean up the mess for the next run. All of which can be the same program, just called with different parameters. Having spent most of my paid experience taking 6 to 24 months cleaning up something that took someone else 3 to 6 months to rush into production. If you do it wrong, not only do you need to fix the problem, but you have to clean up the mess. And that mess can have legal as well as financial implications.
The principle I've always seen is to use the coding style already present in whatever you're working on. If you're creating your own project, you get more freedom. Obviously, you should still follow general rules of good code formatting for whatever language you're using, but they're not specific to Linux.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.