From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5888 invoked by alias); 10 Dec 2010 01:28:54 -0000 Received: (qmail 5880 invoked by uid 22791); 10 Dec 2010 01:28:53 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Dec 2010 01:28:48 +0000 Received: (qmail 31606 invoked from network); 10 Dec 2010 01:28:46 -0000 Received: from unknown (HELO ?192.168.0.102?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Dec 2010 01:28:46 -0000 Message-ID: <4D018246.6010508@codesourcery.com> Date: Fri, 10 Dec 2010 01:28:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFC] mips-tdep.c: Update mips_register_to_value(), et al... References: <20101208164657.7d9ce88e@mesquite.lan> <4D009AE4.9070606@codesourcery.com> <20101209173448.47fe4f14@mesquite.lan> In-Reply-To: <20101209173448.47fe4f14@mesquite.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00127.txt.bz2 On 12/10/2010 08:34 AM, Kevin Buettner wrote: >>> >>> * mips-tdep.c (big_endian_4_byte_fp_reg_with_double_type_p) >>> (eight_byte_gp_reg_with_shorter_type_p): New functions. >> >> Names of these two new functions are a little bit long. :-) > > I agree that they are long, but are they too long? > > Here, taken from the patch, are the various uses of these functions: > > mips_convert_register_p: > + return big_endian_4_byte_fp_reg_with_double_type_p (gdbarch, regnum, type) > + || eight_byte_gp_reg_with_shorter_type_p (gdbarch, regnum, type); > > mips_register_to_value and mips_value_to_register: > + if (big_endian_4_byte_fp_reg_with_double_type_p (gdbarch, regnum, type)) > + else if (eight_byte_gp_reg_with_shorter_type_p (gdbarch, regnum, type)) > > Note that the names are just (barely) short enough that the function > parameters do not need to be placed on a separate line. > Yes, from this point of view, they are not too long. >> Sometimes, it is hard to describe function's behavior only by its name. >> Can we name them as mips_convert_register_p_{1,2}, and give comments in >> details to each of them? > > That could be done. I would prefer to use names that are a bit more > descriptive though. I think that the names that I have chosen, as bad > as they are, still make the code easier to understand than if generic > predicate names were used. I was hoping that someone would suggest some > names that are shorter, but still reasonably descriptive. But, as you > say, that might not be possible. > > Hmm... > > Maybe it'd work out better if I put less detail in the name. How > about these names? > > mips_convert_register_float_case_p > mips_convert_register_gpreg_case_p > > (Or something along those lines...) Looks fine. > > You'd still have to read the code, or possibly a comment, to find > out the precise meaning of the predicate, but the names contain > just enough information so that one won't unwittingly be confused > with the other. It is perfect to use a function according to the description of its name, without reading comments and precise meaning of it. Usually, it might be impossible. Even if we choose "big_endian_4_byte_fp_reg_with_double_type_p" and "eight_byte_gp_reg_with_shorter_type_p" for function names, some people will still have to read the comments, at least, when they want to use them. Personally, I'd like to name function in a reasonably descriptive way, and leave comments in details for that function. -- Yao (齐尧)