优美的代码也是一种艺术

几个月前我完全没有要将代码写得优美漂亮的想法,直到看到一段非常优美的代码。

为什么要将代码写得优美?因为优美的代码意味着稳定、高效、易读,一段充满未知bug或者冗长罗嗦的代码绝对算不上优美的代码。优美的代码还有一个很重要的作用:让作者感到愉悦。每一个爱好技术的人绝对会因为自己技术上的成就感到身心愉悦。稳定的重要性不言而喻,要做到足够稳定就需要尽可能地去预判代码中可能出现的异常,要做到“尽可能”就需要不断地积累经验和学习他人优秀的编码风格。高效是继稳定之后另一个非常重要的影响用户体验的因素,高效的代码就需要高效的算法来实现。易读就是要让别的程序员能够尽可能地只是通过代码就能知道代码的功能,这一点需要从每个类、方法、变量的名称和尽可能简单的语法上去下功夫。

那么怎样才能写出优美的代码?和每个人对于美的定义不同一样,不同的人对于代码的美意见也不同,下面我将从我自己写得一段我认为比较优美的代码来分析如何从细节去构建一段优美的代码。

下面这段代码的功能是实现将Excel文件中的数据导入到Winform的DataGridView控件中。

在写代码之前我们必须要确定的是命名规则,命名规则对于代码的易读性有着非常重要的作用,我采用的命名规则是:类名采用首字母大写的名词,事件和委托采用第一个单词首字母小写其他单词首字母大写的动名词组合,方法采用首字母大写的动名词组合,静态变量采用全大写用下划线分隔单词,全局变量的基本类型变量采用基本类型的首字母开头加下划线加第一个单词首字母小写其余单词首字母大写的变量名例如:string s_userName,全局变量的类的对象采用下划线开头加类名第一个字母小写加变量名例如: User _u_login,局部变量的命名规则在全局变量命名规则的基础上在每个变量的最前面加上字母小写"l"加下划线(类的实例有微小差别)例如:string l_s_userName User _l_u_login。有了这段命名规则,那么当我整个程序都采用这种命名规则后,任何一段代码只要我看到其中变量或方法的名称就能知道它的作用域和变量类型。

命名规则确定后就是代码的编写。注:部分实现细节未展示

public bool ImportDataFromExcel(string l_s_excelFileName)

{

string l_s_conn = "";

l_s_conn = string.Formart(

@"Provider=Microsoft.Jet.OLEDB.4.0;Data Source =‘{0}‘;

Extended Properties =‘Excel 8.0;HDR=NO;IMEX=1‘"

, l_s_excelFileName);

OleDbConnection _l_e_conn = new OleDbConnection(l_s_conn);

if (_l_e_conn == null) { return false; }

_l_e_conn.Open();

OleDbDataAdapter _l_e_cmd  = new OleDbDataAdapter("select * from [sheet1$]", _l_e_conn);

if (_l_e_cmd  == null) { return false; }

DataSet _l_d_data = new DataSet();

_l_e_cmd.Fill(_l_d_data, "table1");

DataTable _l_d_childTable = new DataTable();

foreach (DataGridViewColumn dgvc in dgv.Columns)

{

if (dgvc.Visible && dgvc.CellType != typeof(DataGridViewCheckBoxCell))

{

DataColumn dc = new DataColumn();

dc.ColumnName = dgvc.DataPropertyName;

_l_d_childTable.Columns.Add(dc);

}

}

foreach (DataRow excelRow in ds.Tables[0].Rows)

{

int i = 0;

DataRow dr = tb.NewRow();

foreach (DataColumn dc in tb.Columns)

{

dr[dc] = excelRow[i];

i++;

}

tb.Rows.Add(dr);

}

dgv.DataSource = tb;

}

时间: 2024-10-17 09:49:45

优美的代码也是一种艺术的相关文章

iOS代码加密的几种方式

众所周知的是大部分iOS代码一般不会做加密加固,因为iOS APP一般是通过AppStore发布的,而且苹果的系统难以攻破,所以在iOS里做代码加固一般是一件出力不讨好的事情.万事皆有例外,不管iOS.adr还是js,加密的目的是为了代码的安全性,虽然现在开源畅行,但是不管个人开发者还是大厂皆有保护代码安全的需求,所以iOS代码加固有了生存的土壤.下面简单介绍下iOS代码加密的几种方式. iOS代码加密的几种方式 1.字符串加密 字符串会暴露APP的很多关键信息,攻击者可以根据从界面获取的字符串

如果40岁了还在写代码,是一种幸福,还是一种悲哀?

今天突然想到一个问题:如果40岁了还在写代码,是怎样的状态? 然后搜了一下,果然已经有人想到了,我们先来看看知乎的神人回答. 曾经有网友在知乎提问:"如果 40 岁了还在写代码,是一种幸福,还是一种悲哀?请考虑国情,别老拿外国作比方." 下面是其他一些知乎网友的回复: 马上就 40 了,依然在写代码,写各种代码,从C/C++写到 object-c,从 java 写到 lua,乐在其中,享受得很. 当然,我现在基本不是依靠写代码挣钱谋生,事实上,我也几乎也没有纯粹依赖过写代码谋生过.写代

40 岁了还在写代码,是一种幸福,还是一种悲哀?

天光,一檐停风聚天下闲士 半阁藏卷窃古今名家 马上就40了,依然在写代码,写各种代码,从C/C++写到object-c,从java写到lua,乐在其中,享受得很. 当然,我现在基本不是依靠写代码挣钱谋生,事实上,我也几乎也没有纯粹依赖过写代码谋生过.写代码只是一种乐趣,一种爱好. 当然,难道是写代码谋生就一定是痛苦的吗?也未必. 公司有两个同事,都是非常棒的程序员,也是成熟的架构师,一位是77年的,一位是78年的,他们主要的工作内容都是写代码,他们也都乐在其中,事实上,如果不出意外,他们能够在公

分享:40 岁了还在写代码,是一种幸福,还是一种悲哀?

马上就40了,依然在写代码,写各种代码,从C/C++写到object-c,从java写到lua,乐在其中,享受得很. 当然,我现在基本不是依靠写代码挣钱谋生,事实上,我也几乎也没有纯粹依赖过写代码谋生过.写代码只是一种乐趣,一种爱好. 当然,难道是写代码谋生就一定是痛苦的吗?也未必. 公司有两个同事,都是非常棒的程序员,也是成熟的架构师,一位是77年的,一位是78年的,他们主要的工作内容都是写代码,他们也都乐在其中,事实上,如果不出意外,他们能够在公司里继续留下一起合作,我想他们会一直写代码写到

思考:不放心别人动自己还没有完善的工程代码,是一种什么心理?如何破局这种想法?

思考:不放心别人动自己还没有完善的工程代码,是一种什么心理?如何破局这种想法?我这边比较在意的有:对象和方法的命名的(可读性),DTO(等值对象的)的结构易扩展性,代码结构(方法和对象粒度)的可伸缩性(能够方便扩展和简单改写就能执行并行),还有非功能性比如异常的处理,日志收集等:还有一点是健壮性:包括内存的使用上,流程的阻断上,线程池的使用上等.思想上:自己负责的事情,自己上点心另外要同理心(尽量独善其身)别把自己逼太紧,更不要把别人逼太紧(做事搞砸一般先是处理人际关系除了问题,处理人际关系是第

关于是否要有代码规范的四种观点的看法

1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 答:代码规范是为了统一代码的风格和形式,方便所有人理解,这实际上降低了维护和更新软件的时间好成本. 2.我是个艺术家,手艺人,我有自己的规范和原则. 答:就算自认为是艺术家,编程的艺术也不是通过一些小的规范和形式表现出来的.服从一种代码规范并不会限制一个程序员的创造力. 3.规范不能强求一律,应该允许很多例外. 答:根据某些项目的特别需要,可以有一些针对这些项目优化过的代码规范,但大部分项目应该仍然通用一种

[Html]Jekyll 代码高亮的几种选择

序 新年第一炮,轻松加愉快的,来完成一些年前准备写的文章.Jekyll 中格式化代码有很多种方式,在这里说说几种的实现方式. Jekyll Jekyll 是一种通过模版和数据编译为HTML的工具,说是工具,但是也可以说是服务,如果借助Github(搭建有Jekyll服务,可以实时编译)可以做出半动态网页:对于没有自己服务器的朋友来说是不错的选择. 一般情况下,使用Github+Jekyll来搭建博客和一些说明性质的网页. 之前有发表WIN系统下搭建的文章:[环境搭建]Windows下安装Ruby

提高 PHP 代码质量的 36 种方法

1.不要使用相对路径 常常会看到: 1 require_once('../../lib/some_class.php'); 该方法有很多缺点: 它首先查找指定的php包含路径, 然后查找当前目录. 因此会检查过多路径. 如果该脚本被另一目录的脚本包含, 它的基本目录变成了另一脚本所在的目录. 另一问题, 当定时任务运行该脚本, 它的上级目录可能就不是工作目录了. 因此最佳选择是使用绝对路径: 1 2 3 4 define('ROOT' , '/var/www/project/'); requir

依赖在代码中的几种表现形式

1.依赖关系用虚线加箭头表示,依赖关系是五中关系中耦合最小的一种关系 2.依赖关系的三种表现形式(以动物和水为例): (1)Water类是public的,Animal类可以调用它. (2)water类是animal类中某个方法的局部变量,则animal类可以调用它.代码如下: <span style="font-family:KaiTi_GB2312;font-size:18px;">class Animal { public void Metabolism() { Wat