• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 289
  • Last Modified:

c and procedual programming

What technical problems have been associated with procedural programming as it relates to large scale software development?
0
stupid2
Asked:
stupid2
1 Solution
 
ResonanceCommented:
Well, once you start getting large, procedural code in general (and C in particular) can become more difficult to debug and maintain than the more abstract OO-ish languages.  C in particular suffers from code that easily allows minor programming errors to become REALLY nasty; even little things like off-by-one errors when dealing with a character array can destroy the terminating \0, and become vehicles for the program to overwrite random bits of memory. Nested pointers can become very hard to read, copied/pasted code can severely bloat the size of a project, and the code itself can become difficult to easily reuse in other programs.

On the other hand, simply because it is easy to write bad code in C doesn't mean experienced programmers WILL write bad code in C.  A good programmer who specializes in procedural languages can and probably will provide better results than a mediocre programmer in a "safer" language.  And certainly object oriented languages have their own problems.  Ask a C++ programmer about unsafe inheritance some time.
0
 
GleasonGuyCommented:
Sounds like a take home test to me.
0
 
Ernest022699Commented:
Sure smells like homework to me too.
0
The eGuide to Automating Firewall Change Control

Today‚Äôs IT environment is constantly changing, which affects security policies and firewall rules. Discover tips to help you embrace this change through process improvement & identify areas where automation & actionable intelligence can enhance both security and business agility.

 
basantCommented:
Read Some OOP book First Chapter.
0
 
leondangCommented:
There is no hard proof that OO is easier to maintain than procedural systems in large scale projects.  How has it been that the Linux kernel (and other unix kernels) be so well maintained even though they contain so much code?

Counter example - MS develops Wind*ws in C++ and OO, but this has proved one thing to me - total unmainability and still growing :-)
0
 
Ernest022699Commented:
Having been part of a team which developed an Interactive Voice Response (IVR) / Computer Telephony Integration (CTI) Application Programming Interface (API) in C, having used both C and Graphical User Interface (GUI) development tools, it is my opinion that when a programmer wants to clone an application to produce a new application it is far easier to cut and paste lines of code (sometimes including whole functions) than to copy and modify GUI-based stuff.
0
 
xbillCommented:
Large-scale software development benefits primarily from two things: constructs for the organization of code (usually into modules) sitting atop the actual executable language, and language features to prevent "code explosion" at the level of what a programmer must (re)write and maintain, similar to the phenomenon of template bloat.
<br>
In more mainstream languages, large-scale organization of code is accomplished by packages in Java, and unfortunately C and C++ don't really have real systems. Standard ML and Caml variants have a module system which is much more featureful than Java's, and may be used quite effectively to organize and structure programs.
<br>
The techniques to prevent "code explosion" at the program source level generally all fit into one category: features of the type systems. Object-oriented languages such as Java and C++ (and Eiffel, Smalltalk, Sather, ...) offer inheritance as a method of code reuse across data types. Other languages offer parametric polymorphism to allow code which is independent of some component of an argument's type to be abstracted with respect to that type. Still other languages are entirely typeless, and achieve the benefits of parametric polymorphism by simply not enforcing any restrictions on the types of the arguments passed.
<br>
While nothing inherent in procedural programming prevents procedural languages from having module systems or parametric polymorphism (inheritance would make them object-oriented), most existing procedural programming languages do not offer these constructs or language features. C, C++, and Fortran remain entrenched in file inclusion and macro preprocessing. On the bright side, C++ has (a somewhat nasty version of) parametric polymorphism.
<br>
Personally, I recommend moving to more advanced languages to facilitate large-scale program development.
0
 
sdivyakoluCommented:
The following are the some of the problems we may face when the system is implemented  in Procedural language.

1) Reusability of the code is not supported
2) There is no data hide in procedural Languages.
3) Global pollution of variables
4) Keeping track of variables in various modules.
0
 
leisnerCommented:
I don't think there's an answer to this question.

This technical problems with all software.

Perhaps, fundamentally, is to try to shrink the size of applications...perhaps by having multiple programs, rather than a kitchensink application.

I don't think either procedural or oo
will necessarily help (good procedural is far better than bad oo).

There's no silver bullet.

0
 
Ernest022699Commented:
Unfortunately, sdivyakolu is not correct.

1) Libraries are created by programmers.  Code can be reused by cut and paste.

2) Data are hidden by abstraction.  The use of structures (similar to objects), pointers to structures, and limiting knowledge of the internals of the structures to specific functions (similar to objects' methods) makes a procedural language able to hide data nicely.

3) The use of global variables should be kept to a minimum in any system.  (Vide supra re structures.)

4) Variables should be named appropriately.  There is no excuse for having a variable which is known module-wide having a name such as "i" or "count".

In sum, programmers need to keep the need for maintenance in mind.
0
 
jjmcdCommented:
As Ernest points out, good practices are required in procedural -OR- OO languages to keep large applications maintainable.  Interestingly enough, they are pretty much the same practices.

One nasty I have observed - although type-safe languages such as Java can dramatically reduce the occurrence of some sorts of bugs, they introduce other sorts of bugs which are very much more difficult to understand.  Agreed, these are rarer, but because they tend to be so much more subtle, they can introduce just as much time into debugging.

leisner was right when he says there is no silver bullet.  The overall best answer is to have a good, repeatable process so that you can continually improve.  Without a process, you're only shooting in the dark when you try to move to improve things.  Not that you might not get lucky, but you also might bankrupt your company.

This is why the CMM, ISO and the TUV all focus on PROCESS.  They don't care what languages, procedures, or what methodology you use, as long as it's repeatable and documented(well, that's maybe not 100% true in the case of the TUV, who says they don't care about your methodology but their requirements can't be met without waterfall).

Whether OO or procedural, you can't be counted on to reliably develop software without a reliable, repeatable process.  This is why more and more companies are requiring CMM certification of an organization contracted to write software.

If I contract a CMM 3 or 4 organization to do software, I can be pretty confident I'll get what I asked for on time and on budget.  If the organization is 4 or 5, I can be sure it will be high quality as well. If you have no certification, I can count on being surprised, and more than likely, the surprise won't be pleasant.
0
 
abdijCommented:
Hi Man,
  I was following this thread for quite a while. The more you speak the more confused the situation gets. Let me put the idea this way.

In real life we value Data more than the pocedure. In structure programming the stress is on the procedure to manipulate a data rather than the data itself.

The problems associated with procedural languages like C is that it is difficult to implementlarge life projects. Since everything is procedure oriented a large team is bound to do the following errors:
1. Write redundant code. For example each programmer might have his own Error handling mechanism (which might ultimately be common across many others).
2. Mismanage data. As the data flows across the interface functions the data may get curropted. Its especially proven so with pointers. Since pointers can be manipulate its easy to defunk your code.

Ultimately the time to integrate and execute the project increases.

But it does not end there.

Imagine a bug is reported during testing. To trace the source of bug sometimes each of the interfaces need to be checked. This is beacuse data has been left hand treatment.

Even so the maintainance is a bigger problem. Assuming a new programmer is put in to maintain the code. On a new bug he might treat (read mistreat)the data in his own way. If the work is huge ultimately another round of tracing and retracing is required.

Whatever i have explained is what we have experienced and is just the tip of the iceberg. Of course there are lot many related issues. You might want my mailid : abdij_b@hotmail.com. Feel free to ask.

Coming to OO.

Its not God. But definatelt it is a messenger of god. But if the thinking is not changed OO is a waste. OO is not a notation it is the way you think. You can still write a class that is nothing but a structure with data as well as functions within it. No. Thats not how it should be visualized. OOPs allows you at least avoid the disasters that normally occur in the software life cycle. With a minimal effort you cab have classes to handle all the commonalities and make it available to all the modules so that redundancy is avoided.
Again with minimal effort you can expose your data to only modules that really need them, thus disallowing the misuse of data.
There are so many other advantages of OOPs that every OOP/ C++/Java book will tell you.

But unless you think OOP and prcatise it the problems of Structure programming are to remain. OOPs allows you to do things in a better way than that possible in Structure methodology.

Hope you got what you wanted.

Thanx.
Once again feel free to reply.
0

Featured Post

Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now