From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424356AbdD1Qkn (ORCPT ); Fri, 28 Apr 2017 12:40:43 -0400 Received: from mail-qk0-f175.google.com ([209.85.220.175]:33056 "EHLO mail-qk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755022AbdD1Qkf (ORCPT ); Fri, 28 Apr 2017 12:40:35 -0400 MIME-Version: 1.0 In-Reply-To: <1491893636-60759-1-git-send-email-lenohou@gmail.com> References: <1491893636-60759-1-git-send-email-lenohou@gmail.com> From: Andy Shevchenko Date: Fri, 28 Apr 2017 19:40:34 +0300 Message-ID: Subject: Re: [PATCH v1]] lib/btree.c: optimise the code by previously getpos function To: Leno Hou Cc: "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 11, 2017 at 9:53 AM, Leno Hou wrote: > This patch optimized the code by previously getpos function call. > Therefore, It's takes the convenience to understand logic of code. Besides what Christoph told you (I agree with him, writing test suites / modules is quite good exercise for newbies) my 2 cents for below code that you may consider in the future as a technique of cleaning up, > +static int getpos(struct btree_geo *geo, unsigned long *node, > + unsigned long *key) > +{ > + int i; unsigned int i; > + > + for (i = 0; i < geo->no_pairs; i++) { > + if (keycmp(geo, node, i, key) <= 0) > + break; Here you return directly return i; > + } > + return i; And here is the best to return negative error code instead, like return -ENOENT; > +} > for ( ; height > 1; height--) { > - for (i = 0; i < geo->no_pairs; i++) > - if (keycmp(geo, node, i, key) <= 0) > - break; > + i = getpos(geo, node, key); > if (i == geo->no_pairs) > return NULL; Taking above into consideration you may do i = getpos(geo, node, key); if (i < 0) return NULL; Rationale behind that: 1) getpos() return value may be directly used whenever we need return code to return; 2) you hide implementation details in your helper function (geo->no_pairs dereference). Though here both of them kinda minors you may use such technique in the future for more complex code. -- With Best Regards, Andy Shevchenko