Wikipedia talk:WikiProject Computer science

Draft: Brainchip

could someone review the Draft:Brainchip page? Birdmanoftech (talk), 13 January 2023 (UTC)

Hamming distance

The Hamming distance article is a bit vague in its introduction; see my question and a response to it at WP:RD/MA. Could someone reword the introduction so its error-counting is clearer? Nyttend (talk) 21:25, 11 June 2025 (UTC)

What is vague about "the number of positions at which the corresponding symbols are different"? Put another way, what other interpretation or interpretations did you have in mind that the correct interpretation might have been confused with? I see you have some hints of this in your RD/MA question but you seem to have overlooked the word "positions" and focused only on the symbols. —David Eppstein (talk) 21:54, 11 June 2025 (UTC)

need help with the Flynn Taxonomy page

Flynn's taxonomy is a high-importance topic with 371 pages linking to it. however until I started editing it, it had absolutely no reference whatsoever to Flynn's 1972 paper (actually written in 1970 under a US Govt Atomic Energy Commission Contract). Images are needed which illustrate the 3 types of SIMD that Flynn drew in figure 5 of the 1972 paper but I cannot find anything. some help needed as the topic is very hard to understand without a graphic. Lkcl (talk) 07:30, 1 August 2025 (UTC)

ECLR-attributed grammar

Is this notable - or not? It's been tagged as unsourced for 11 years and tagged even longer for notability concerns. There are external links. Please help us resolve this issue once and for all. Pinging Wikiacc. Bearian (talk) 21:27, 3 August 2025 (UTC)

We could merge ECLR-attributed grammar, L-attributed grammar, LR-attributed grammar and S-attributed grammar into new individual sections of Attribute grammar. The sizes of the articles involved seem conducive to this treatment. I realize I'm not answered the question you've asked but perhaps it's a usable answer. ~Kvng (talk) 14:31, 7 August 2025 (UTC)

More opinions needed at Talk:V_(programming_language)

Disputed edit and the corresponding discussion thread. Thank you. TurboSuperA+_[talk] 18:02, 2 September 2025 (UTC)

C/C++ pointer asterisk and null checks

C and C++ do not have official guidelines on where to place the asterisk in a pointer declaration. There are tradeoffs for each (which I do not want to waste time going over), but I believe it should be enforced consistently throughout Wikipedia to have as little confusion to the reader as possible. As C and C++ are extremely connected languages, and knowledge in one often translates to (at least some) knowledge/interest in the other, I think the same convention should be enforced equally to both C and C++ topics. That is, of course, deciding whether to write Type *x or Type* x - proponents will argue that the former implies that *x is of type Type, while the latter implies x is of type T*. Personally I think the former is more flawed, and while this does tie back to personal preference, I believe that the former does introduce more confusion and reduce clarity - for instance, that same logic for a void pointer would imply that in void *x, *x is of type void, however anyone with knowledge of any C-style language would know that this is meaningless as void is not a type that is stored in memory.

I also would like to address null checks in if statements, particularly if (p != NULL) vs if (p). Proponents of the former argue that it is clearer, while proponents of the latter argue it is idiomatic as pointers implicitly convert to boolean values and a null pointer will evaluate to being false. I see the latter as being more concise and idiomatic, while the former is redundant (after all, C/C++ is not Java, there is no need to force such a check). While clarity is, as mentioned in the previous point, important in Wikipedia, it should not come at the cost of redundancy and verbosity, and that which can be abstracted away should be abstracted away when it makes sense to. In my opinion this is one such case.

Ideally, we should also seek to use more modern features when possible and emulate modern styles of programming rather than antiquated ones. This means, avoiding things like Hungarian notation names, avoiding pointless whitespace aligning, replacing /* multi-line comments */ when a comment spans only one line (and can thus just be replaced with // single-line comments, etc.

Please give me your thoughts below. 24.50.56.74 (talk) 22:50, 16 September 2025 (UTC)

I think this is best left to local consensus rather than having a wiki-wide style. Sohom (talk) 23:05, 16 September 2025 (UTC)

It is cumbersome to hold a talk page for consensus on each topic, especially when most things are the same when being in the same language. I don't think it makes a whole lot of sense to do that personally. 24.50.56.74 (talk) 13:08, 17 September 2025 (UTC)

Agreed. We don't have absolute site-wide standardization on spelling and grammar and this is similar. There is consensus that these things should be consistent within an article. ~Kvng (talk) 14:40, 22 September 2025 (UTC)

It's not feasible to hold a talk page for every single page that has something to discuss. Either way, what you would suggest would still mean I would make the edits I want to make and address talk pages where objections exist, after all I am probably the only one particularly interested in changing this. Only @Vincent Lefèvre has voiced opposition, based on "convention" which I am making this talk page to specifically address. 24.50.56.74 (talk) 20:31, 22 September 2025 (UTC)

IMHO, the discussion should occur only at one place. I suspect that other contributors did not pay attention to the changes and are not aware of this discussion. Let's ping them: Cedar101, Kbrose, and Warudo for the main ones. Note that both the ISO C standard and the GNU Coding Standards use the Type *p writing. Ditto for major software such as GCC (even in its C++ code), the GNU C Library, and the Linux kernel. — Vincent Lefèvre (talk) 23:25, 22 September 2025 (UTC)

For C++ code, the C++ core guidelines use Type* p, so I do think that this is the style that should be adopted for C++. While GNU Coding Standards may use a different style for whatever reason, for clarity I defer to the reasons I gave above. 24.50.56.74 (talk) 14:55, 23 September 2025 (UTC)

But earlier you said: As C and C++ are extremely connected languages, and knowledge in one often translates to (at least some) knowledge/interest in the other, I think the same convention should be enforced equally to both C and C++ topics. Do you want both C and C++ to use Type* p or only C++ to use it? I think this is wrong by the way. We should do what is customary in each language even if it different. I see nothing wrong with using Type* p for C++ code but Type *p for C code. (I'm not saying that's what I want, I'm only saying there's nothing wrong with it.) Warudo (talk) 15:09, 23 September 2025 (UTC)

As I said earlier, I would prefer that both use the same style, but that there is a compelling case for C++ whereas with C both Type* p and Type *p are about equally popular. I think Type *p however has various problems of its own, such as void *p suggesting *p is of type void (which obviously is nonsensical). 24.50.56.74 (talk) 15:43, 23 September 2025 (UTC)

And Type* p, q; falsely implies that q is a pointer to Type. Both approaches have problems, it's just a matter of personal preference which problem one thinks is more important. Warudo (talk) 15:45, 23 September 2025 (UTC)

Type* p, q; is discouraged against by Bjarne, saying it's better to just declare one variable/object per line. I'm not trying to treat his word as gospel but I do think that these two have different extents to how much they can "mislead" a reader, and we should pick what would be the least confusing. 24.50.56.74 (talk) 15:54, 23 September 2025 (UTC)

Bjarne's opinion is important for C++ but not necessarily for C. One could also question how often people are mislead into thinking that *p is of type void in your example, but that's not the point. The point is that this stuff is and always will be subjective. I might like one more, you might like the other. So, I've been convinced that an WP:ENGVAR style approach where the styling is decided on a per-article level is the way to go here. Warudo (talk) 16:05, 23 September 2025 (UTC)

Only @Vincent Lefèvre has voiced opposition. I also oppose using Type* p for C code for the same reasons. I'm neutral for C++. Perhaps a style advice page on C and C++ would be good to have although I'm definitely not volunteering to write it myself. Warudo (talk) 15:04, 23 September 2025 (UTC)I'll strike this because, on second thought, I'm neutral for C as well. Warudo (talk) 16:00, 23 September 2025 (UTC)

I don't care for this level of consistency myself across all computer science articles, especially given that different pages will have very different audiences who might be exposed to very different coding standards. (To give a concrete example, if you need to illustrate modern browser code, you would probably use modern C/C++ syntaxes (reflecting similar code in Chromium or Firefox), whereas for something like the page on C (programming language) itself, you would probably want to be much more careful and write code that is compatible across multiple variants of compilers and ISO C standard compliant Sohom (talk) 15:18, 23 September 2025 (UTC)

I'm willing to write it if that's something we decide on and everyone is willing to give their thoughts on what would be appropriate to include in it. 24.50.56.74 (talk) 15:44, 23 September 2025 (UTC)

This looks like a solution in search of a problem. We don't need an encyclopedia wide-standard anymore than we should standardize tabs vs spaces, curly brace on same line vs curly brace on new line, or indeed standardize vs standardise. MrOllie (talk) 16:01, 23 September 2025 (UTC)

A lot of things on Wikipedia have standards (some de-facto) that probably don't need them, but I only responded to User:Warudo's suggestion of a style advice page. It's just a possible way forward, not the only way forward. 24.50.56.74 (talk) 16:05, 23 September 2025 (UTC)

I think Sohom has a point. It's a possible way forward but not a good one. Warudo (talk) 16:06, 23 September 2025 (UTC)

I was wrong on that one. Mea culpa. Warudo (talk) 16:07, 23 September 2025 (UTC)

It looks like there aren't any new responses or objections, but I'm still interested in pressing the matter. I'm going to wait a little more (say a week or two) before I proceed with my changes if no one else has objections to raise. 24.50.56.74 (talk) 21:15, 30 September 2025 (UTC)

Folks don't have to renew their objections on any kind of schedule. There is no consensus for standardizing the style, so you should not do it. MrOllie (talk) 21:30, 30 September 2025 (UTC)

Right. There is no consensus here for wide-spread changes to Wikipedia. I myself agree that such style issues should be handled on an article-by-article basis, like so many other things in Wikipedia. Mgnbar (talk) 00:36, 1 October 2025 (UTC)

The only places where those changes apply are in the pages C data types, C file input/output, Union type, and Pointer (computer programming) and for the most part the only one who actively disagrees is @Vincent Lefèvre. I'm just going to move this back to the original discussion where that took place since evidently no one here feels strongly about anything enough to settle it here. 24.50.56.74 (talk) 01:12, 1 October 2025 (UTC)

You've got people actively disagreeing right here. I'll reiterate my stance above - I disagree. You should not do this. MrOllie (talk) 01:53, 1 October 2025 (UTC)

And note that the style Type *p is used by ISO C and other major sources related to the C language (major software and books). Moreover, there are no reasons to change other style when the current style in a WP article matches what can be found in such sources, even though some sources may differ (i.e. keep what the original authors have written in such a case). — Vincent Lefèvre (talk) 08:21, 1 October 2025 (UTC)

In places where I made changes to pages, you reverted my edits even when the scope of my edits extended beyond the placement of *, such as changing comments from /* */ to //. For example, Pointer (computer science). I made edits that extended beyond the placement of the pointers and yet you still reverted it, even when the changes I made are arguably not "just" changing style but also addition of content. The same applies to the other pages I listed. 24.50.56.74 (talk) 13:24, 1 October 2025 (UTC)

You didn't make anything clear. All you said was say that it was a "solution in need of a problem" and say that you disagreed with standardising the location of where the * is placed (We don't need an encyclopedia wide-standard anymore than we should standardize tabs vs spaces, curly brace on same line vs curly brace on new line, or indeed standardize vs standardise., Folks don't have to renew their objections on any kind of schedule. There is no consensus for standardizing the style, so you should not do it.). Same goes for User:Sohom Datta. 24.50.56.74 (talk) 13:17, 1 October 2025 (UTC)

That you do not find our disagreements to be 'clear' does not mean that you can act as if no one is disagreeing. MrOllie (talk) 13:34, 1 October 2025 (UTC)

Maybe write clear disagreements next time? 24.50.56.74 (talk) 14:33, 1 October 2025 (UTC)