Talk:Gotcha (programming)

Latest comment: 6 months ago by Equinox in topic Not a programming-specific term

The text is from Eric S. Raymonds Jargon File, which is in the public domain. See [1] for details. D.Cutter 15:14, 4 Feb 2005 (CET)

Why I deleted the Transwiki tag edit

Gotchas are potentially vast subject and it is extreeeeeemly useful to have a page warning people of some of the common gotchas.Dejvid 11:20, 13 August 2005 (UTC)Reply

Notability edit

Googling for programming gotcha yields 619,000 hits. Clearly it's notable, though I'm not sure how to "establish" this in the text. More examples in more languages would help. Perhaps a reference to books on the subject, such as Koenig's C Traps and Pitfalls? Tualha (Talk) 10:04, 26 October 2006 (UTC)Reply

Number of hits in Google does not establish notability. The phrase "purple donkey" yeilds 1,480,000 results. This article should either be broadened to include every kind of gotcha (including those having nothing to do with computers)-- or deleted. Gotcha is a general term. (-XDXFP 4:13PM / Nov 17th)

Okay. This is clearly a topic that's not confined to be a dicdef. Gotchas as a programming term are well known among programmers. Thus, probably notable (we don't have notability guide for technical concepts, though, but the gut feeling says this is important). If the article was expanded to cover more on the usage, then this would be definitely notable. I'll thus remove the notability tags and tag it for expansion instead. --wwwwolf (barks/growls) 14:39, 1 December 2006 (UTC)Reply

In my opinion this article not notable and could be deleted. Gotcha is a generic term and this article could equally be called "programming pitfalls" or "one line programming errors". Quimn (talk) 00:41, 3 May 2020 (UTC)Reply

Gotchas in the C programing language edit

This section is about C programming language but the example code is written in C++. —Preceding unsigned comment added by (talk) 01:19, 27 September 2007 (UTC)Reply

yes and this function parathesis is NOT a gotcha, you just HAVE to know how declarations are working. if you do it 'by eye' then i agree. and == = := is kind of corect (talk) 00:41, 22 January 2008 (UTC)Reply

#IF 0 up to #ENDIF should be deleted. It's a syntax error. The "gotcha" in the C function example foo; is a very good gotcha however - it compiles fine and does nothing of value - it puts the address of the function on the stack, whereafter the address is dropped. ... said: Rursus (mbork³) 17:08, 21 November 2009 (UTC)Reply

Gotchas in Ruby programming language edit

Iterating Range edit

I don't think this is a gotcha. The example in particular works as expected. A (3..1) Range does not include any element. It's an empty one, since the initial element of the Range is bigger than the final one. Since it's an empty range, iterating over it produces no output, correctly and unsurprisingly.

I think this particular gotcha should be removed.I have removed this gotcha.

It's still a gotcha because it behaves not the way people expect it to (which would be, iterating backwards: 3,2,1). It may be by design, but it's still a poor design that leads to errors. -- Wesha (talk) 17:58, 9 November 2010 (UTC)Reply

Returns from the block edit

As a ruby beginner wannabe, I simply don't understand the example. I think it could be improved by showing where something has been defined, explaining what the return will actually return from (Boo(), AFAIU). It is also unclear to me why “the code in transaction() taking care of that will never be executed if something==true”. Does it means that the code after the return in transaction will not be executed? This is the normal behaviour I would expect. shtrom (talk) 02:27, 16 May 2010 (UTC)Reply

Well, what we have between do and end is actually an anonymous, isolated code block, that gets passed as a parameter to function transaction(), and as such one would expect return() to return from that particular block. Function transaction() internally looks like:
def transaction(*params)
  # open the transaction...
  yield # Execute the passed-in block
  # close the transaction...
The problem is that when you return() inside the block, the remainder of transaction() after yield will not be executed, i.e. transaction will NOT be properly closed in the DB. -- Wesha (talk) 18:06, 9 November 2010 (UTC)Reply

Relevance of Examples edit

Wikipedia is supposed to contain a description of important information relevant to the topic and perhaps a notable example or two simply as illustration. This article is composed almost entirely of examples. Wikipedia simply is not an exhaustive list of every possible thing that may potentially be confusing to a majority of people. I don't think the page should be deleted, but I do think that the entire contents of it should be thrown out and the article re-written. Anyone have any thoughts? Westphjm (talk) 19:45, 1 May 2012 (UTC)Reply

Belatedly, your advice was acted upon. I deleted the whole unreferenced example farm. A reference to a reliable source must attest that the particular case is a notable "gotcha", i.e., a very common source of programmer's mistake. I can name a dozen of these right out of my head. Such as having items named aValidNameOfATop and aValidNameOfABot and confuse them by cut and paste. Or name a variable 'tmp' and re-use it in two distant pieces of code, and then next coder modifies the code accidentally removing re-initialization of 'tmp'. Or zillion of other sloppiness a compiler will never catch. Staszek Lem (talk) 17:06, 17 August 2015 (UTC)Reply

I agree that this article is not the place for an "example farm", but differ with the rationale, namely that every "particular case" of a notable topic must itself be notable. Certainly concepts such as "person", or many particular species, are notable; but it would be misleading (and sometimes difficult) to limit oneself to notable examples.Sderose (talk) 17:32, 5 December 2017 (UTC)Reply

Not a programming-specific term edit

This is just the normal word "gotcha" meaning a trap. I don't see why it deserves a special programming-specific page. Equinox 20:16, 18 November 2023 (UTC)Reply