<< Back To All Blogs
Diversity In Software Engineering Methods
Thursday, October 12th, 2006
I thought that I would post my thoughts on the conventions and differences of conventions within software engineering. To me this is the biggest problem with software engineering today. While coding standards and naming conventions are often required within schooling for Computer Science, naming conventions and coding standards at most jobs are either non-existent, or are not enforced. Part of this problem lays within the fact that all programmers have naming conventions and programming methods that they feel are proper, and do not like to vary from these at all. I myself am guilty of this, as I think most programmers are. You will find that almost all programmers vary on ideas and concepts underlying software engineering, in both naming and programming conventions, as well as the theoretical aspects underlying programming in itself. Software Engineering is inherently difficult in practice, and laid on top of software that has been written and modified by multiple programmers at different times, especially from different companies, this makes the programming of existing software even more difficult. I have broken the regions of programming down into the following categories, with my thoughts on all of the topics discussed below.
1. Naming Conventions
This is a big deal in programming. Functions and classes in my mind should be named by the overall function or functions that they operate upon. Classes should be named by their underlying general principal, so a class that would create and manage users should be named class User. The underlying functions within the class should be named whatever the function does. So a function that creates a new user within the User class should be called User->createNewUser(). Notice that I have lowercased the first phonetical name of the function. I always do this with functions, but alot of programmer to not. I also denote private variables and functions by preceding with a _, whereas alot of programmers do not. You will find that most programmers that started in C++ do this, as it is common practice within C++. Another problem with naming conventions is expandability. While a function originally created in software may have a very specific function, modifications to this code at a later time may lead the core purpose of the function to be totally different. A recent example of this is where a program had a function named checkIfInteger(). While the name implies exactly what it says, what the function was really doing was checking if the value passed was a floating or double number. This resulted from the original purpose of the function being modified later, and to reduce program-wide code changes and naming changes, the function was simply modified without changing the name that states the purpose of the function.
2. Layout of Code Blocks
This is another big difference in programming styles. I myself have always put parenthesis on the same line as the function, to reduce lines used for both readability to understanding. In this area I would say that I am in the minority. Most programmers today put parenthesis on their own line, especially programmers that use Visual Studio and other Microsoft products that automatically complete parenthesis and put them on their own line by default. While this seems like a minor problem, if you are used to reading code that is designed in one way or the other, it takes longer to comprehend and modify code that is written outside of what you are used to.
3. Database Design
This is a big problem that is ever-growing as applications require more portability and exchange of information between different programs. I am speaking on this for the most part about MySQL and Microsoft SQL Server, but this also applies to other databases, such as Oracle, which require specific naming conventions to be passed in code. Naming conventions for databases vary widely, some prefer to prefix table names with tbl, or stored procedures with Sp_name. While this makes sense in a command-prompt type programming environment, where it may not be incredibly clear as of to what type of data you are working with, in my mind, if you are creating a stored procedure, or a cursor, etc, you already know what kind of data type you are working with, therefore prefixing these data types is overkill.
4. Code Methodologies
As programming languages expand, and require backwards compatibility, as well as programming languages maintaining functions and aspects from languages upon which they were derived, there are usually multiple ways for a programmer to complete a function. This is very apparent in PHP. Programmers that are used to C and C++ are likely to use printf and sprintf for printing output, whereas programmers that started with PHP before C++ and C are likely to use print and echo for outputting information. Once again, if you are used to viewing code in one way, reading code from a programmer that does the opposite makes it longer to comprehend the purpose of the function, and therefore increases programming time.
I have outlined my views on some things that make software engineering all the more confusing and hard to understand. This is simply from my point of view, and I'm sure that others will disagree with some of the things that I have said above. However, These are all still problems that keep every programmer at bay, and can be quite frustrating if you have every been in these situations before.
Currently no comments.
Add A Comment
Email Address: (not public, used to send notifications on further comments)
Enter the text above, except for the 1st and last character: