Talk:Programming style

From Wikipedia, the free encyclopedia

	This article is within the scope of WikiProject Computer science, which aims to create a comprehensive computer science reference for Wikipedia. Visit the project page for more information and to join in on related discussions.
B	rated as B-Class on the assessment scale
Mid	rated as mid-importance on the assessment scale

Contents 1 Article Name 2 Tabs Versus Spaces 3 Modified Examples 4 By Programmers For Programmers? 5 Programming for begginners (Support of Willfulwizard) 6 software anomalies 7 Coding Standards 8 Added a bunch of stuff from "programming bug" 9 C Sharp and the Left-hand Comparison Style

[edit] Article Name

I moved an article to coding style. To me, programming style sounds like functional programming or procedural programming or OOP-style. -- Taku

I've moved it back, "programming style" gets 91200 google hits, while "coding style" gets 87700. Anyway, functional, procedural, OOP refer to elements of the language that technically matter, while style technically doesn't, but it's preferred. Dysprosia 05:43, 29 Oct 2003 (UTC)

Agreed. It seems a paradigm sounds more suitable for functional programming or OOP. -- Taku

Would it be worth making a link in the intro to Programming paradigm, for people searching for the style of problem solving, as opposed to the style of source code organisation? I hit this node when looking for the other... -- Sinewalker 00:35, 17 January 2006 (UTC)

[edit] Tabs Versus Spaces

"In the C-family languages, it is also recommended to avoid using tab characters in the middle of a line as different text editors render their width differently."

I'm not so sure about this portion of the article. There are varying opinions on whether one should use tabs or spaces. It would be nice if the article mentioned the converse position. - 24.74.31.172 08:49, 8 December 2005 (UTC)

I agree that this needs to be explored objectivly, and also feel that its location in the article needs to be re-evaluated. Willfulwizard 19:42, 13 September 2006 (UTC)

[edit] Modified Examples

I modified the time examples so their purpose made more sense. Previously, the example given was along the lines of

get a, b, c; if( a < 12 && b < 60 && c < 60 ) ...

with the explanation that the code will return TRUE if the time specified is in the morning. However, this is inaccurate on several accounts; primarily, the code is actually returning TRUE if the time is in the morning AND the time is a valid time. Ironically, a code example in an article on programming style is indeed in poor style.

I modified the examples to be:

get a, b, c; if( a < 24 && b < 60 && c < 60 ) ...

with the explanation that the code returns true if the time is a valid 24-hour time.

Also, the examples for indenting and spacing overlapped. Before and after examples should vary by only the style element being discussed. I've corrected these 2, but I haven't carefully looked at the others. Willfulwizard 19:42, 13 September 2006 (UTC)

[edit] By Programmers For Programmers?

The page lacked basic info for non-programmers, so I added it to the intro. I also created a code appearence section, and reformatted based on that. Article still needs more basic info and clarity. I'll get back to it sometime if no one else does. Willfulwizard 19:42, 13 September 2006 (UTC)

[edit] Programming for begginners (Support of Willfulwizard)

I truly support the last contribution from Willfulwizard which talked about making your progamming webpage a bit easier for the begginners. I am learning programming on my own but u some sometimes make certain things very difficult to understand for me. anyway, more oil to your brain and more of your tutorials.Richkorku 14:58, 19 December 2006 (UTC) Richard

[edit] software anomalies

Hello, my addition to the "see also"-link: Anomaly_in_software was removed on 24th December.

Please rethink, because I think this would be appropriate.

Reason is following:

there are analytic and constructive quality assurance measures. Most people see failure/anomalies during analytic quality assurance measures, but in fact the bug happened much earlier. And this is why constructive quality assurance measurement is important. And to this constructive quality assurance measures belongs programming style/guidelines/conventions. So, if I can prevent bugs/failures right from start, this is the best. But how do we do this? By strict applying the guidelines? Perhaps - but imagine now a fresh developer, who has no experience, (s)he will definitely argue, why some part of the guideline is like this and not like that. And perhaps not apply one part, which could result in a failure, which costs time to fix.

For this, experience helps and this means knowing bugs/failures/anomalies, then people will see the advantage of programming style.

And who of you did not improve his/her style because there happened once a very bad bug? Don't we learn from our errors?

I would appreciate any discussion on the matter. See also one of the reasons, why the article was introduced here. BTW: this article "Programming style" uses already 2 times terms from anomalies (faults, computer bug).

Thx, for your comments in advance. ----Erkan Yilmaz (evaluate me!, discussion) 15:49, 27 December 2006 (UTC)

Erkan_Yilmaz (so everybody else knows, it was me who removed the link), your article on software anomalies looks at faults/bugs from the end user perspective (or at least that is how it reads to me). Programming style is deals with how software developers write code and is not directly connected with how a user of a program views its behavior. When I read your article on software anomalies I thought it was a duplicate article and that it was very similar to the article on software bugs/faults. Then I reread it and understood that you were dealing with the more general subject of software requirements and end user expectation. So it is not a duplicate article. I think the link between software anomalies and programming style is very weak. The link to software bugs is stronger because that article deals more directly with programmers. I hope this explains my reason for removing the link. Derek farn 16:23, 27 December 2006 (UTC)

Hello Derek farn,

thank you for the fast answer.

I knew that you deleted it, because we had a talk already, where in the process I updated the article, but I wanted to also see the group's view on it. SO, there is no blaming here or edit-war, I just would like to have more feedback by others also.

So, what already helped me is, that there were probs with the article:

1. looks at faults/bugs from the end user perspective (or at least that is how it reads to me)

2. I thought it was a duplicate article and that it was very similar to the article on software bugs/faults

Then I reread it and understood that you were dealing with the more general subject of software requirements and end user expectation

I will try to implement these into the article, so it can be better seen. I put them for now here. As you see, every feedback helps improving the articles. Thx for this valuable info. ----Erkan Yilmaz (evaluate me!, discussion) 18:27, 27 December 2006 (UTC)

Hello Erkan_Yilmaz, my comments were not a list of problems with the Anomaly_in_software article. The intent of my comments was to help you understand why I thought that a link from programming style to anomalies in software was not appropriate (the same argument also applies to your question about why I removed the link from the source code article). Derek farn 18:51, 27 December 2006 (UTC)

Hello Derek Farn, well I know, but I also could use them to improve the article. So there is a win already. :-) About the link of the articles, I tried to explain below, why I believe both articles belong together. But after I have changed the article I guess there is nothing to say against a link ? ----Erkan Yilmaz (evaluate me!, discussion) 18:57, 27 December 2006 (UTC)

About:

>Programming style is deals with how software developers write code

>and is not directly connected with how a user of a program views its behavior.

Actually everyone in a project should consider the wishes of the stakeholders. And mostly in the end, the customer pays the money (or you develop it internally for your organization, but still there are then other stakeholders).

So, if you know, that this specific customer has a real problem with this certain bug, then you know, let's try to not make this bug again and would use it in your style.

Also for example, if you use code appearance (indenting, spacing) or using "Appropriate variable names" you can work better in reviews, this could mean, finding more anomalies itself. And we all know, that the sooner you find a bug, the less it costs (well that is the normal belief, argument on another time :-) ). But the earliest way is not to make a bug or find it with a review, e.g. pair programming in XP or more formal reviews.

Anyway, people should always do riskmanagement and this goes better, if you can use experience.

E.g. if you know that the old project used programming Language X and there is a new project now, which also will use X as language. And you have knowledge, that in X itself there are bugs (remember please: X is just software), which caused failures in your application, you can prevent these bugs by writing in the guidelines.

But also, if you use design patterns, there are better ones and not so good ones. You can explain, that with design pattern Y1 this specific anomaly will not happen, but when using pattern Y2, it could.

Also: there are different software development models/approaches, e.g. TDD, BDD, where before real code is written test-code. And this works better, if you know what kind of anomalies to prevent. ----Erkan Yilmaz (evaluate me!, discussion) 18:27, 27 December 2006 (UTC)

[edit] Coding Standards

I tried removing it a couple days ago, but apparently it was reverted because "The linked to page contains useful information." So, am I missing something, or is there a reason why we have a link to coding standards. As far as I can tell, it simply redirects back to this page. Which to me seemed pointless. When I clicked the link, I expected to be reading a different article, instead I'm back where I started. AlReece45 00:03, 4 March 2007 (UTC)

I was the person who put the link back. Your right it now redirects back here. It used to contain a different article. Is there some kind of alternate edit going on here? I will investigate. Derek farn 11:48, 4 March 2007 (UTC)

So, what did you find?DewiMorgan 19:39, 10 May 2007 (UTC)

[edit] Added a bunch of stuff from "programming bug"

I added a bunch on bug-preventing programming style, to the Software bug page. But it really works better here, so I lopped it back out of that page, put it in here, and expanded on it with examples. Please build-on/simplify these new bits! :) If you think them inappropriate, feel free to yell at me. Would "defensive programming" be a better place for these things?DewiMorgan 19:39, 10 May 2007 (UTC)

[edit] C Sharp and the Left-hand Comparison Style

Hello User_talk:ACardboardRobot! Funny GMTA issue with your mod to Coding_standard#Left-hand_comparisons. I had originally included C# in that list, but then took it out because I read at C_Sharp_(programming_language) that:

C# disallows this "integer meaning true or false" approach on the grounds that forcing programmers to use expressions that return exactly bool can prevent certain types of programming mistakes such as if (a = b) (use of = instead of ==).

So the technique (Left-hand comparsisons, the subject of the article section) is not needed with C#. There could still be = versus == confusion if one were comparing booleans, as: if (variable == false) but that's a pretty lame way to say if (!variable) . Funny thing, the example already in the article is doing some even more lame boolean comparisons, comparing with true, so I changed that too (to the integer 42). So please tell me what you think. I hope you like the revisions. Bob Stein - VisiBone (talk) 13:27, 1 February 2008 (UTC)