Talk:Code bloat

Computing Mid‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Mid	This article has been rated as Mid-importance on the project's importance scale.

Software: Computing High‑importance

	This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware articles
High	This article has been rated as High-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

Quality

"code bloat' is the production of [...] that is perceived " .... Perceived, by whom? tortal

The Javascript algorithm used as an example should at least have a small sentence describing what it does. That would make it easier to understand the example. Also, for the shorter "non-bloated" version - it is commented with "simplified". Is it truly _simpler_ to read and understand? If so let it be. Otherwise one might instead call it optimized. tortal

Removed the following, as it seems NPOV: why pick on Microsoft, when Adobe, Corel, and HP also have been accused of shipping bloatware? jkl 17:10, 12 February 2006 (UTC)[reply]

> Many people refer to code produced by Microsoft as bloatware.

Merge

Code bloat is a notable topic but i'm not sure if this deserves a own article when there also exist a article about software bloat in general. Both topics are also adjacent and the other article Software bloat is more factual. A other suggestion is more addition of references and info about detection of code bloat in proprietary software. --Off! 11:50, 18 April 2006 (UTC)[reply]

Merge discussion

See Talk:Software bloat for that. MichaelBillington 12:35, 13 July 2006 (UTC)[reply]

Type mapping for avoiding code bloat in C++

Hi, would mentioning type mapping as a technique to avoid code bloat in C++ a good point? I can write it if so. Dgutson (talk)

Yes, I would like to see more examples of code bloat elimination techniques. (If the example gets too specific for the "code bloat" encyclopedia article, then the example will be moved to a better location -- some more specific C++ article or Wikibooks: C++ -- and this "code bloat" article will link to that better location). --68.0.124.33 (talk) 15:49, 24 March 2008 (UTC)[reply]

The type of bloat being discussed here is code that produces a large executable binary and is likely to refer to an actual machine-code binary rather than byte code as is produced by a language such as Java. As such, it is most likely to refer to code written in C++ or C. —Preceding unsigned comment added by 212.58.232.179 (talk) 13:01, 23 August 2010 (UTC)[reply]

A few points from the Example section state that overuse of OOP causes Code bloat without reasons that make sense

I always believe that breaking an algorithm into many methods is a good way to simplify the code and to increase readability. I think the Example section needs to be edited, if it's possible by using a valid reference or some code samples to prevent misleading. —Preceding unsigned comment added by Mimi tan1985 (talk • contribs) 08:50, 1 March 2010 (UTC)[reply]

I second that. The part quoted below is completely bogus, and the phrasing suggests a beginner with irrational style preferences wrote it.

Other than the remark on algorithmic efficiency (which is not influenced at all), the opposite of every assertion made in the quoted text is actually true:

It's code repetition causing code bloat (as opposed to re-use of functions). It's huge functions which are hard to read/understand (as opposed to small functions making calls to a handful of well-named other functions), and better readable is also better debuggable.

And what did the author refer to by "OOP methods/functions/procedures" ?

EDIT: I replaced the line with an explanation for the opposite, and provided a reference to an article of a highly regarded author on such subjects.

I also find several other of the items in that list suspicious and screaming "beginner with attitude" (an irrational anti-OO one, veiled a bit), but since IMHO there is *some* truth to some of them, and I have no time to properly refine those, I'll leave it at this remark here.

"breaking an algorithm up into many methods is a way to allow developers to reuse these methods to solve other problems. However, this often adds code bloat and makes the code difficult, if not impossible, to read and debug and reduces algorithmic efficiency."

Unshaven (talk) 12:56, 19 July 2012 (UTC)[reply]

Examples

A terrible examples. Turning a code into mess with a long array doesn’t mean simplifying it. Is it that Java cannot optimize\simplify the so-called complex code? 80.243.6.98 (talk) 13:38, 10 December 2018 (UTC)[reply]