Talk:Programming style

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)

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)

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)

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)

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

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)

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)

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)

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)

Howto tag - removed

User:Thumperward, on 26 July, added a howto tag, with the comment "(too much prescription in here)". However, he failed to follow the instructions on the page to which the tag links ("There is currently no consensus as to how the how-to articles should be edited. To-do lists may be replaced with great prose, or more simply, introduced in a way that reduces their how-to nature. Please discuss the issue on the talk pages, so that good guidelines for editing can be established.") as there was not even the briefest note, let alone any discussion, left on the talk page.

A howto is a step by step pedagogical guide to doing something: this is not a howto. I can't see how to have this article without defining the main traits of good coding style. I can't see a way to clearly explain those traits, and explain why they are GOOD style, without examples showing both good and bad. It's an article on style. Of COURSE it shows how to do it wrong, and right. There's no other way it could do it. That's not "too much prescription", that's "explaining it clearly".

It seems to have been a flyby tagging by someone with no prior or subsequent input into the page, on a quest (per his user page) to "de-howto wikipedia". I have placed the following note on Thumperward's user page, so he has the chance to argue the point:

I've removed the "howto" link from Programming style, for the following reasons: The tag requires a rationale to be posted to the talk of the article: none was posted. The tag is for articles with a "howto" section: this article does not have one, nor any step by step methodology that might be even distantly construed as a howto. The tag has been there for months, with nobody attempting to obey it. I'm perfectly happy for the tag to return, but it needs a reasoned rationale (which I don't have to agree with!), and examples or explanations of how the page could be changed in order to be "better".

Thoughts? Am I being too "bold"? DewiMorgan (talk) 02:21, 19 October 2008 (UTC)

I've re-tagged it as an essay. The article has only one reference at this time, and advances a great deal of arguments. It also presents material in an educational rather than descriptive manner. I'll see if I can work on this myself in future. Chris Cunningham (not at work) - talk 10:04, 22 October 2008 (UTC)

*grumble* To be honest, I reluctantly but completely agree there. While it's all good stuff on the page, and all true and best practice, and I love the page for being there for me to point newbies at... it's not so well referenced as it could be, and so on. I'd hate to see it heavily pruned of information, but would be nice to be less... well, yes, less essaytacular. I can't think how that could be done without castrating the page though. Will be very interested to see your changes, if you can find the time to have a poke. DewiMorgan (talk) 23:46, 27 October 2008 (UTC)

On the other hand, I didn't notice you deleted the references in order to support your "This article has only one reference at this time" claim. While I feel they should be used as references, rather than a big ol' list o' links, I don't feel deletion is the best way to accomplish this, since the content of the page refers to the information in them. I admit I can't see a clean way of doing this. Linking all the relevant ones after each point that refers them would be messy. Linking each one only once, when it is first applicable, would be just confusing. Some kind of table might be the way to do it most concisely, and would clearly and usefully display the information about which languages have which style issues (for example, VB won't have style rules about lefthanded assignments, or any of the curly-brace issues). But I've no idea about wiki markup for that sort of thing. And while easier on the eyes, a table may be less encyclopaedic in style than just a long list of refs after each section. DewiMorgan (talk) 23:50, 29 October 2008 (UTC)

The content is still there in the page history, if anyone wants to dig through it while working on the article. I didn't trust that the current state of the article was such that it had been derived from the references, and that even if it were it would likely be a case of drawing new conclusions from the combination of disparate sources. I've got the page watchlisted, so I might even work on this myself at some point. Chris Cunningham (not at work) - talk 20:17, 31 October 2008 (UTC)

Deleted from "Tabs"

I deleted the following passage: "There are also some tricks that people do since it is easy to work with tabs. Since most programmers have the tool to replace a certain text with another text, people use it to replace the tab then for spaces."

My reasoning there is: the first sentence essentially says "there's cool stuff you can do with tabs", but doesn't say what, nor give references for these cool tricks (is setting tabstops or tab sizes a "trick"?), so seems a nonsequitir. The next sentence seems to to be bad advice, claiming "people can search/replace tabs with spaces". Um... not with a regular search/replace, you can't. With a regex search/replace, you can just about manage it (I can't see a way with just a single pass, though). Which is why most decent programmer's editors have tab conversion as a separate option, just because a naïve search/replace of them will mangle the code.

For example, naively replacing the tabs with 8 spaces in:

1       8
1234567 8

will give:

1        8
1234567        8

So, a nonsequitir, and bad advice.DewiMorgan (talk) 00:16, 30 October 2008 (UTC)

Wikilink to a psychology article in the "See also" section

If the psychology article The Magical Number Seven, Plus or Minus Two "provides a rationale for some style decisions", as User:Derek farn puts it, then this should be explained in the text of the article, rather than simply being thrown upon the "See also" section (leaving to the poor reader the work of guessing the relationship between the subject of this article and the topic of that one).

The connection between the article The Magical Number Seven, Plus or Minus Two to this article has not yet been clearly stated, therefore I have removed it from the "See also" section. Naturally, if the connection is explainable and supported by reliable sources, there will be no problem in adding a wikilink of that psychology article to the body of the article (together with the sourced explanation, properly integrated to the remaining text). --Antonielly (talk) 19:00, 8 April 2009 (UTC)

Code Conventions

This article overlaps with Coding conventions and Coding standards and has no proper link to de:Programmierstil. I dare not change it, because I cannot decide which of the two articles could go to orcus or if both could get a clear different lemma. --Brf (talk) 15:46, 11 December 2009 (UTC)

See also

I think that this link would be relevant there: Motor_Industry_Software_Reliability_Association —Preceding unsigned comment added by 82.108.154.19 (talk) 15:18, 26 January 2010 (UTC)

Vertical Alignments

Python gives some good arguments against vertical alignment that are not in this article. The gist is: if you always align your variable definitions (or declarations), you may create semantic relationships where there are none and distract from the intended meanings by violating the proximity principle (things that are closer to each other appear to be more related to each other). The bug mentioned in the example should therefore be avoided altogether by defining the search/replace values as a mapping rather than as two disjunct lists.

As the original point/counter-point conclusion already sounds a bit argumentative, I can't think of a good way to add this without making it sound like a forum discussion --- 78.35.103.86 (talk) 08:54, 28 April 2010 (UTC)

Hrm. I think that you're trying to make two points: 1) "Where stuff's not related, vertically aligning it to match is not useful". Well... yeah. But that has no bearing on the point in the article, which is that, when stuff IS related, vertically aligning is very useful indeed.

2) "In the minimal example given, there's a completely different way to re-code it that would avoid the problem." - it's in the nature of trivial examples of problems, that trivial alternative routes to the same end can be found that avoid the problem completely. However, that doesn't mean that the problem does not exist: a mapping/hashtable is not always the most efficient solution to a problem, not all languages have a decent mapping syntax, and if you replace that array definition example with function calls, #defines, or whatever-you-fancy that can't use a mapping, then the problem remains.

So, I can't really see that either point applies. But then, I may be misunderstanding, and so inadvertently strawmanning, what you wrote. DewiMorgan (talk) 03:43, 22 September 2010 (UTC)

As an addition, in the book "Clean Code" Robert Martin ("Uncle Bob") suggests that Vertical Alignment is a poor choice as it emphasizes the wrong things in that it leads you to look at the types (if using a language which requires type identifiers) as a group, identifiers as a group, and the values being assigned as a group thereby distracting you from the correlation between individual type, identifier, and value. — Preceding unsigned comment added by 64.251.74.12 (talk) 20:02, 26 October 2011 (UTC)

The motivating example given is rather poor, if search and replace terms are related then they should be stored in a compound data structure (list of tuples perhaps?) It would seem that relying on formatting to imply a relationship between variables is poor practice (any tool which autoformats the code, which many organizations will require one to use, would cause that linkage to be lost) — Preceding unsigned comment added by 64.251.74.12 (talk) 20:09, 26 October 2011 (UTC)

Merging Programming style and Coding and Naming Conventions articles

Please see following talk page and provide me with some feedback if you like Talk:Coding_conventions#Refactoring_coding_conventions_and_programming_style_articles. Several bigger but straigtforward merges re. following articles are proposed: Programming style , Coding conventions , Naming convention (programming) . Thanks, Ptrb (talk) 12:42, 13 November 2010 (UTC).

Hi, I added merging-info in header of Coding conventions. KR 17387349L8764 (talk) 10:24, 15 April 2021 (UTC)

Vertical Alignment

Currently, in the Vertical Alignment section, there is a citation needed tag for the sentence "Most modern code editors support proportional fonts, and the programmer may prefer to use a proportional font for readability". I'm not sure what it's saying needs citation - that programmers may prefer a proportional font, or that IDEs support it. If it's that IDEs support it, then I think the tag should be moved; if it's that programmers may prefer it, then the tag should be deleted. Of COURSE some programmers prefer it: in any other situation, proportional fonts are generally considered better, so there are some who would prefer them when coding. I would remove the tag myself, but I might not fully understand the policy; it's been there since September 2010, so if it should be removed, I'd think it would have been by now. --71.229.183.111 (talk) 03:43, 9 June 2011 (UTC)

ModuLiq Zero Indent Style

Is "ModuLiq Zero Indent Style" worth mentioning? The only information about it I could easily find in google was in archive.org. If it is really widely used, a reference is needed in the article. If it is given as a curiosity, a reference is needed. Otherwise it should be removed. — Preceding unsigned comment added by 178.42.6.200 (talk) 22:00, 26 March 2013 (UTC)

Haskell style

I wrote an expanded section of Haskell style. But Haskell is a very different language than C, C++, etc. It is a declarative language. i.e. there are no statements like if then else, and loops, because it does not have assignment. The language restrict the use of capital and lowercase letters. All declarations can be entered in any order. Haskell programs are too short compared with all the imperative languages. — Preceding unsigned comment added by 189.233.105.4 (talk) 16:47, 28 March 2017 (UTC)

Hi, Ok good, what else you want to do? There is a overall lack of citations, is this your personal idea of Haskell or common knowledge? Are you planning on improving it? KR 17387349L8764 (talk) 10:26, 15 April 2021 (UTC)

I do not know if i am missing the theoretical background here, but the sentence "Haskell is a declarative language, there are statements, but declarations within a Haskell script." seems to be missing a word, or having another semantic problem (at least in ubiquitious language). Sorry if i am missing something subtle here. 80.139.38.64 (talk) 17:35, 4 September 2021 (UTC)