From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code] Date: Wed, 17 Oct 2018 08:49:08 +0200 Organization: Aioe.org NNTP Server Message-ID: <86y3axgja3.fsf@zoho.com> References: <86tvlvmxtz.fsf@zoho.com> <86woqprcdb.fsf@zoho.com> <8636tcl05a.fsf@zoho.com> <8636t9k1sj.fsf@zoho.com> <86y3b0ibsv.fsf@zoho.com> <86bm7vhuyf.fsf@zoho.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1539758912 6001 195.159.176.226 (17 Oct 2018 06:48:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2018 06:48:32 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Oct 17 08:48:28 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCfd5-0001Qs-F4 for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Oct 2018 08:48:27 +0200 Original-Received: from localhost ([::1]:34111 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCffB-0007HK-VT for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Oct 2018 02:50:37 -0400 Original-Path: usenet.stanford.edu!goblin3!goblin.stu.neva.ru!news.neodome.net!news.uzoreto.com!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 67 Original-NNTP-Posting-Host: IYul6C8CwghWjVz/CRhiVw.user.gioia.aioe.org Original-X-Complaints-To: abuse@aioe.org Mail-Copies-To: never X-Notice: Filtered by postfilter v. 0.8.3 Cancel-Lock: sha1:K4Ydp4HJ3QMcAzgZkIGkkDzLJ6k= Original-Xref: usenet.stanford.edu gnu.emacs.help:224168 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:118294 Archived-At: Garreau, Alexandre wrote: >>> On the long term this tends lead to >>> horrible code, where the defuns reflect all >>> the history of the situations, as they >>> arrived, not the problem's structure as it >>> is *now*. >> >> Why is this horrible code? Isn't it just >> natural that the code reflects how problems >> have been solved over time, with changes in >> technology, etc.? > > No, VCSes a here for that. It is a fact of life that code develops and grows in different directions. Different parts of the code reflect more so the original idea, other parts of the code refect more so situations that arrived without anyone thinking of them day one. This is completely natural and not something so you can use the code as a history book, if anyone now got that idea. >> Isn't it much better to have this >> "reflection" in neat modules than in single >> functions spanning 3 A4 each? > > If these modules have no meaning, no, because > it will harden the work of understanding, > thus, for instance, of debugging, the > function. While the same functions may have > piece that will cancel or make useless pieces > of other functions, if you just “add up > historically”, you may, if you want to solve > the problem as it is *now*, simplify the > whole thing. And it won’t simply be > refactoring by adding functions or macros, it > will be removing stuff. The modules should have have meaning and reflect how the problem is solved now. If they, at some point, become totally obsolete, they are much easier to drop as modules than to try to extract that exact portion of the original, 3 A4 long defun, without creating bugs while doing that. >> [1] Better yet, delete *the call* to them >> and to move the modules to an out-of-action >> source file, as history might repeat itself. > > VCS, search tools, or otherwise devs > memories, are here for that. And even if it > stayed in the source code anyway people are > interested in functions that are documented > and that they use, directly or indirectly. > They might as well not see it if it’s > not used. OK, if you have found a spot where they are the most visible, go ahead and use it. To me, an "obsolete-source" directory is fine. -- underground experts united http://user.it.uu.se/~embe8573