From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Przemys=C5=82aw_Wojnowski?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Wed, 14 Oct 2015 13:14:59 +0200 Message-ID: <475156c7af1fea6ddbbd86237d6063b4@mail.iq.pl> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <878u78b3hg.fsf@fencepost.gnu.org> <87h9lwyv33.fsf@gmail.com> <561C368F.6010306@cs.ucla.edu> <87oag3xb2i.fsf@gmail.com> <561D241E.1010902@cs.ucla.edu> <87vbaaagr5.fsf@gmail.com> <86io6amqhd.fsf@gmail.com> <06472760353f91fb2b6a1e427e954a70@mail.iq.pl> <874mhtra55.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1444821444 31714 80.91.229.3 (14 Oct 2015 11:17:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 11:17:24 +0000 (UTC) To: =?UTF-8?Q?Przemys=C5=82aw_Wojnowski?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 14 13:17:09 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmK3N-0000Y5-ML for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 13:17:05 +0200 Original-Received: from localhost ([::1]:41660 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmK3M-00065h-TQ for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 07:17:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmK1P-0005ZN-GL for emacs-devel@gnu.org; Wed, 14 Oct 2015 07:15:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmK1M-0004Wy-Ra for emacs-devel@gnu.org; Wed, 14 Oct 2015 07:15:03 -0400 Original-Received: from smtp23.iq.pl ([86.111.242.228]:42372) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmK1M-0004Va-IP for emacs-devel@gnu.org; Wed, 14 Oct 2015 07:15:00 -0400 Original-Received: (qmail 29346 invoked from network); 14 Oct 2015 11:14:59 -0000 Original-Received: from unknown (HELO roundcube.iq.pl) ([86.111.241.60]) (envelope-sender ) by smtp22.iq.pl with SMTP for ; 14 Oct 2015 11:14:59 -0000 Original-Received: from [89.174.214.74] by roundcube.iq.pl with HTTP (HTTP/1.1 POST); Wed, 14 Oct 2015 13:14:59 +0200 In-Reply-To: <874mhtra55.fsf@gnu.org> X-Sender: esperanto@cumego.com User-Agent: Roundcube Webmail X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 86.111.242.228 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191543 Archived-At: W dniu 2015-10-14 12:56, Tassilo Horn napisał(a): >> Refactorings that increase maintainability (like this one) are very >> useful to other developers. >> >> Such changes, even small, accumulate towards something that can be >> called a "maintainable system". In (wannabe) healthy systems it is >> everyday practice. > > OTOH, they reduce the helpfulness version control offers to new and old > developers. I.e., it's good when "git blame" shows you the last > changes > which actually changed the code, and switching "char const *" to "const > char *" or vice versa are no real changes. Why? In git you've got full file history. Besides the latest message gives you nothing if it doesn't explain why something was changed. "Fixed the issue" types of messages are basically useless. Important is: write to a person in the future why you do what you do. > In the same vein, it's of course good to have one consistent > indentation > style, one consistent style of setting braces, one consistent style of > naming variables, etc. This is the first thing every team does after deciding that they want to have a maintainable system. In teams that are not used to constant refactoring, people always start with "But history!", "Don't fix what's not broken!", etc. But after sometime they admit that it was a good change. In theory it's scary, in practice it works. In maintainable (readable, understandable) systems developers can read many things from the code and don't have to look into VC history all the time.