MTK代码的最大问题

hztianxie · 发表于 2010-4-30 13:41:35

最大的毛病无非就两个：
1：宏太多，而且是宏套宏，跟个套娃似的，用DEFINE，而不是用显而易见的

#if XXXX 1
#if xxxx 0
等等

2：把全部系列的芯片都集合在一个程序里，代码管理混乱，这个其实可以归为毛病1

3：毫无编程规矩，改对奇的没对齐，
最鄙视这种写法

void mtk_xxxxx{
if(){

}else{

}

}
不知道是哪个人教MTK那些个工程师这么写的？

hztianxie · 发表于 2010-4-30 13:44:58

这么多宏，除非是MTK的项目经历，否则谁知道哪些该关，那些该开，严重影响代码阅读速度

把程序做成傻瓜式的，只要在feature ON OFF就行了，但是这样的代价却是巨大的。

虽然可以一搜就可以根据某个开关知道全部的代码。但是本人不欣赏这样的做法，代码写的好的话，完全可以很轻松的知道来龙去脉。

hztianxie · 发表于 2010-4-30 13:46:15

还有，忘了说一点，命名的问题，我真想揍那些MTK的工程师。

WC 原来是WORLD CLOCK

这个名字很长吗？要你这么缩写干吗？

hztianxie · 发表于 2010-4-30 13:47:47

补充:
类似下面的，我真不知道，为什么编译时要复制一份

直接用一份难道不可以吗？

Mmi_features_video.h (e:\work\kl01s1\plutommi\customer\custresource): #define __VDOREC_FEATURE_WB_FLUORESCENT__
Mmi_features_video.h (e:\work\kl01s1\plutommi\customer\custresource): #define __VDOREC_FEATURE_WB_FLUORESCENT__
Mmi_features_video.h (e:\work\kl01s1\plutommi\customer\custresource): //#define __VDOREC_FEATURE_WB_FLUORESCENT__
MMI_features_video.h (e:\work\kl01s1\plutommi\customer\custresource\pluto_mmi): #define __VDOREC_FEATURE_WB_FLUORESCENT__
MMI_features_video.h (e:\work\kl01s1\plutommi\customer\custresource\pluto_mmi): #define __VDOREC_FEATURE_WB_FLUORESCENT__
MMI_features_video.h (e:\work\kl01s1\plutommi\customer\custresource\pluto_mmi): //#define __VDOREC_FEATURE_WB_FLUORESCENT__
MMI_features_video.h (e:\work\kl01s1\plutommi\mmi\inc): #define __VDOREC_FEATURE_WB_FLUORESCENT__
MMI_features_video.h (e:\work\kl01s1\plutommi\mmi\inc): #define __VDOREC_FEATURE_WB_FLUORESCENT__
MMI_features_video.h (e:\work\kl01s1\plutommi\mmi\inc): //#define __VDOREC_FEATURE_WB_FLUORESCENT__

hztianxie · 发表于 2010-4-30 13:48:40

我坚信一点：

好的程序架构+好的编程风格，本身就是一部好教材

废话不多说了，发泄下而已

hztianxie · 发表于 2010-4-30 13:58:00

delete delete

hztianxie · 发表于 2010-4-30 14:01:00

delete delete

davidson · 发表于 2010-4-30 14:10:03

等楼主自己开发个一个MTK平台出来，就明白了。

hztianxie · 发表于 2010-4-30 14:13:02

以下是引用davidson在2010-4-30 14:10:03的发言：
等楼主自己开发个一个MTK平台出来，就明白了。

我目前也是新手，入行才2个月，对很多东西不是很了解

我就编程方面说一下，功能方面，我还在抓紧学习中。

shenz · 发表于 2010-4-30 15:13:34

楼主真能侃,

blindfly · 发表于 2010-4-30 18:07:41

我最不喜欢的是代码里面一大堆缩写。CCAV不让缩写我反对，代码里不让缩写得厉害我就支持，哈。

ffhh · 发表于 2010-5-1 02:52:01

楼主说的是有道理，MTK代码架构并不好，结构，资源处理，nvram等都很落后，只是做久了，系统稳定度提高以后其他都是次要的。其实国内很多嵌入式软件开发公司的代码架构比MTK要好，只是他们所处的行业不像手机这么大而已
你说的宏定义的问题，在mmi_feature.log里有总汇，可以查那些define，那些没有define

setagllib · 发表于 2010-5-1 21:18:00

台湾公司至少可以弄一个手机软件平台，并且产业化，国际化，不要抱怨太多，除了架构没有搭好，代码写得还是不错的。自然不能和linux kernel比。
不要要求太多。
再说了，人间的方案就是turn key,本来就希望你直接生产呀，呵呵

wangzhengh · 发表于 2010-5-2 16:53:56

虽然也比较讨厌MTK的这套宏，但是站在MTK的立场上，它有那么多芯片，每个芯片都有上百个客户，每个客户的需求都不一样，不通过宏来控制，恐怕MTK再多几百号人都无法维护那么庞大的代码。
再看看展讯平台的代码，从R平台到L平台，代码就已经改得面目全非了。试想一个在R平台上开发了三个月的客户，现在要切换到L平台，这个客户在R上改动的代码如何在短时间内porting到新的L平台上？

aquasnake · 发表于 2010-5-3 14:36:36

以下是引用wangzhengh在2010-5-2 16:53:56的发言：
虽然也比较讨厌MTK的这套宏，但是站在MTK的立场上，它有那么多芯片，每个芯片都有上百个客户，每个客户的需求都不一样，不通过宏来控制，恐怕MTK再多几百号人都无法维护那么庞大的代码。
再看看展讯平台的代码，从R平台到L平台，代码就已经改得面目全非了。试想一个在R平台上开发了三个月的客户，现在要切换到L平台，这个客户在R上改动的代码如何在短时间内porting到新的L平台上？

展讯平台R上的驱动porting到L，两天可以了

MOCOR整合6600R，6600L，6800，甚至我个人已经尝试整合6600H

aquasnake · 发表于 2010-5-3 14:40:57

以下是引用hztianxie在2010-4-30 13:44:58的发言：
这么多宏，除非是MTK的项目经历，否则谁知道哪些该关，那些该开，严重影响代码阅读速度

把程序做成傻瓜式的，只要在feature ON OFF就行了，但是这样的代价却是巨大的。

虽然可以一搜就可以根据某个开关知道全部的代码。但是本人不欣赏这样的做法，代码写的好的话，完全可以很轻松的知道来龙去脉。

这个在C文件中尽量不要去动，应该是在全局make文件中控制，并写好注释，一目了然。所谓的perl编译控制环境，实际上和IDE类似，只不过用脚本语言写能够更精确定制化，相当于一个批处理

hztianxie · 发表于 2010-5-4 09:10:15

以下是引用wangzhengh在2010-5-2 16:53:56的发言：
虽然也比较讨厌MTK的这套宏，但是站在MTK的立场上，它有那么多芯片，每个芯片都有上百个客户，每个客户的需求都不一样，不通过宏来控制，恐怕MTK再多几百号人都无法维护那么庞大的代码。
再看看展讯平台的代码，从R平台到L平台，代码就已经改得面目全非了。试想一个在R平台上开发了三个月的客户，现在要切换到L平台，这个客户在R上改动的代码如何在短时间内porting到新的L平台上？

其实你可以看看MTK的对手公司MSTAR,也是一家台湾公司

同样是芯片公司，同样有N多的DH追随，MSTAR的方案是分开的，独立的，A芯片一个程序版本，B芯片一个程序版本，规划的比较好，而且编程风格也不错。

而且MTK这样做，自己累死，设计公司的开发人员又学不到什么东西。

我之前的设计公司，很多方面速度上超过原厂了。为什么？因为我们从来不做开开关管的动作，就算是原厂做好的代码，我们也要查看，是不是正确，是不是有改进的地方。

所以我们会把整个代码的来龙去脉搞的非常熟，当然，优点很多，缺点也有，就是开发进度会比较慢点，尤其是前期。

但是同一系列的芯片足够多，我觉得还有可行的，比如，MSTAR的AXXX BXXXX CXXXX DXXXX 芯片,架构一样，风格一样，就是功能不同，那么你第一个项目架构改好，其他项目，基本可以做到半个月到1个月就可以量产.当然第一个项目可能就需要3-6个月。人员配备大概是2个软件 1个硬件

如果就单一芯片，另外的芯片程序架构完全不同了，那就没必要采取这样的做法

hztianxie · 发表于 2010-5-4 09:17:20

相比MSTAR，MTK把本来应该是DH做的事情，自己包揽了。

而且MTK的代码，我觉得做的好的话，完全可以吧代码行数压缩掉2/5。

当然，我本人没试过，也不想试，否则工程量太大了。MTK刚开始的路就走的有点急功近利了。

我之前做过一个程序，就是把三个不同项目，集成在一个程序里面，同一芯片的不同应用不同客户，就觉得程序可读性就不是很好了，MTK的各芯片都放一个程序了，可想而知了

hztianxie · 发表于 2010-5-4 11:05:35

刚看到AUDIO PLAYER这一段

哎，头疼

两个开关

#if defined(CFG_MMI_AUDPLY_MULTIPLE_LIST) && ((CFG_MMI_AUDPLY_MULTIPLE_LIST == __ON__)||(CFG_MMI_AUDPLY_MULTIPLE_LIST == __AUTO__)) && (defined(__MMI_AUDIO_PLAYER__))
#ifndef __MMI_AUDPLY_MULTIPLE_LIST__
#define __MMI_AUDPLY_MULTIPLE_LIST__
#endif
#endif

#if defined(CFG_MMI_AUDPLY_SINGLE_LIST) && ((CFG_MMI_AUDPLY_SINGLE_LIST == __ON__)||(CFG_MMI_AUDPLY_SINGLE_LIST == __AUTO__)) && (defined(__MMI_AUDIO_PLAYER__))
#if (defined(__MMI_AUDPLY_MULTIPLE_LIST__))
#error "Wrong option! '__MMI_AUDPLY_MULTIPLE_LIST__' and '__MMI_AUDPLY_SINGLE_LIST__' shall be mutually exclusive."
#endif
#ifndef __MMI_AUDPLY_SINGLE_LIST__
#define __MMI_AUDPLY_SINGLE_LIST__
#endif
#endif

=================
我觉得完全可以这样解决，

1:定义枚举，
enum
{
AUDIO_PLAYER_TYPE_MULTIPLE,
AUDIO_PLAYER_TYPE_SINGLE
}

#define AUDIO_PLAYER_TYPE AUDIO_PLAYER_TYPE_MULTIPLE

这样只会选一个，不会出现两个都定义的问题，也不用#error 了

程序中就用
#if（AUDIO_PLAYER_TYPE == AUDIO_PLAYER_TYPE_MULTIPLE）

#else//single

#endif

wangzhengh · 发表于 2010-5-4 16:12:28

以下是引用aquasnake在2010-5-3 14:36:36的发言：
？
展讯平台R上的驱动porting到L，两天可以了

MOCOR整合6600R，6600L，6800，甚至我个人已经尝试整合6600H

R/L驱动改动相对较少，但是MMI改动是非常大的，MMI Kernel的影响全局的部分数据类型改了，GUI控件也改了不少，Porting之前的MMI代码到L上非常痛苦，并且同一个模块，要兼容R和L的代码非常困难。
而在MTK上，这种改动是基本不可能发生的。

		自动登录	找回密码
密码			注册

[讨论] MTK代码的最大问题